Bugzilla – Full Text Bug Listing
| Summary: | Determine if disabling should also clear values in certain cases | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Konstantin Komissarchik <konstantin> |
| Component: | Sapphire | Assignee: | Project Inbox <sapphire.ui-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Konstantin Komissarchik
No. Just because something caused a property to be disabled doesn't mean that all trace of it should be wiped from the file. Disabled properties can still have non-null values and user might want to go back to those values. There are cases where it is advantages to null out some properties in response to certain user actions, but those should be taken on the case-by-case basis with good justification. The log case outlined here doesn't strike me as one in need of this treatment. From Ram Venkataswamy: ---------------------- Check this use case: - open override dd - create Management | MBeans | JMX MBean - On Design view, select MBean | Factory - input/select values for Factory & Accessor fields Now, switch back to Query / Class In the source view mbean-accessor is retained. I will start an e-mail thread with Troy. The current behavior is as designed. There is an e-mail thread going to determine if we'd like to revisit the original design decision. Making this into an enhancement request and deferring to the next release. The record of the e-mail thread: From: Ling Hao [mailto:ling.hao@oracle.com] Sent: Wednesday, June 09, 2010 4:20 PM To: konstantin.komissarchik@oracle.com; raj.alagumalai@oracle.com; troy.beecroft@oracle.com Cc: greg.stachnick@oracle.com; ram.venkataswamy@oracle.com; shenxue.zhou@oracle.com; danny.ju@oracle.com; nadeem.aboobaker@oracle.com; andrew.fernandez@oracle.com Subject: RE: Handling of existing values when a property is disabled I vote that irelevant values should be cleared. But wouldn't it be nice, even if just for the current session, when I switch back, the values that was cleared magically reappears. :) ________________________________________ From: Konstantin Komissarchik Sent: Wednesday, June 09, 2010 4:13 PM To: Raj Alagumalai; Troy Beecroft Cc: Greg Stachnick; Kodandaraman Venkataswamy; Ling Hui Hao; Shenxue Zhou; Zhijun Ju; Nadeem Aboobaker; Andres Fernandez Subject: RE: Handling of existing values when a property is disabled Let’s leave the specific jdbc descriptor case to the other thread. Let’s see. To review the opinions… Ram thinks that at least in enum case, values that are no longer relevant should be erased. He opened the original bug that prompted this discussion. Raj prefers to retain values. Troy prefers to clear values in both enum and boolean case. Konstantin prefers to clear values in enum case, but has moderate preference for keeping values in the Boolean case. Anyone else wants to voice an opinion on this? - Konstantin From: Raj Alagumalai [mailto:raj.alagumalai@oracle.com] Sent: Tuesday, June 08, 2010 1:26 PM To: konstantin.komissarchik@oracle.com; troy.beecroft@oracle.com Cc: greg.stachnick@oracle.com; ram.venkataswamy@oracle.com; ling.hao@oracle.com; shenxue.zhou@oracle.com; danny.ju@oracle.com; nadeem.aboobaker@oracle.com; andrew.fernandez@oracle.com Subject: RE: Handling of existing values when a property is disabled I like the current behavior where the values are held across sessions. One of the arguments against this approach is that the user after x iterations might not know which entries are required and which were left behind. I think in this case the user has the option to switch to the default state by using the restore defaults wizard. Konstantin, I’m seeing the exact opposite happen with the jdbc.xml file. The user creates a single data source and configures the file. At that point, if the multi data source checkbox is checked, all the configuration is lost. I think we should provide the user with an option to revert back to the single data source. Let me know your thoughts. Thanks Raj From: Konstantin Komissarchik Sent: Monday, June 07, 2010 11:28 AM To: Troy Beecroft Cc: Greg Stachnick; Raj Alagumalai; Ram Venkataswamy; Ling Hao; Shenxue Zhou; Danny Ju; Nadeem Aboobaker Subject: RE: Handling of existing values when a property is disabled Let’s keep this at the level of UI patterns for now. We do not need to decide on a single approach. It is fine to have a different approach for different UI patterns. In our implementation, case 1 and case 2 have a lot in common, but it is not clear to me that these two are very similar from user’s perspective. For instance, in case 2 (enums), the disabled values are not shown. I can imagine that in user’s mind “not shown” can translate to “don’t exist”. That mental sequence will not happen in case 1 (boolean). I would also not dismiss from consideration the types of problems typically modeled by these patterns and user’s expectation in those situations. Other people on this thread should feel free to jump in on the discussion. No need to be shy. :) - Konstantin From: Troy Beecroft [mailto:troy.beecroft@oracle.com] Sent: Saturday, June 05, 2010 2:51 PM To: konstantin.komissarchik@oracle.com Cc: greg.stachnick@oracle.com; raj.alagumalai@oracle.com; ram.venkataswamy@oracle.com; ling.hao@oracle.com; shenxue.zhou@oracle.com; danny.ju@oracle.com; nadeem.aboobaker@oracle.com Subject: RE: Handling of existing values when a property is disabled The fact that in some cases user may want to temporarily switch off and retain configuration seems hihgly dependant on the semantics of the properties rather than the form of the UI. So unless you're suggesting this is one more attribute that can be modeled on a case by case basis (e.g., retain-disabled-values or some such) it still seems like we need an overall approach. If we're trying to decide on a single overall approach, I'm still more inclined not to hang onto these values - especially not across sessions. For the situations like case 1, which may argue for this - I think they tend to be less common relative to the other cases. Also, some of this type of temporary disabling/enabling may be more commonly done via the console than a descriptor. Finally, if you really wanted to keep the values you could also just edit the switch in source - it's a simple workaround to occasionally change a TRUE value to FALSE or vice versa. Trying to model these things on a case by case basis might be fine. But it adds a little more complexity for what seems like it may be potentially small gain. -Troy ________________________________________ From: Konstantin Komissarchik Sent: Thursday, June 03, 2010 5:46 PM To: Troy Beecroft Cc: Greg Stachnick; Raj Alagumalai; Kodandaraman Venkataswamy; Ling Hui Hao; Shenxue Zhou; Zhijun Ju; Nadeem Aboobaker Subject: RE: Handling of existing values when a property is disabled Do you think that case 1 and case 2 should receive the same treatment? It seems to me like user confusion/expectation and likelihood of wanting old values back might not be the same between these. Some things to ponder… In case 1, the user still sees the old values after the property is disabled (so it’s obvious to them that they still exist). Also case 1 is frequently used to turn on/off some parameterized behavior. It seems more likely that the user might want fast swap timeout remembered when they temporarily turn off fast swap. Conversely, it doesn’t seem likely that user will want log file path remembered when they switch from file-based to database-based logging. Note that when I say “remembered”, I mean between sessions, not as some sort of an undo stack. Should these patterns receive different treatment? - Konstantin From: Troy Beecroft [mailto:troy.beecroft@oracle.com] Sent: Thursday, June 03, 2010 4:33 PM To: konstantin.komissarchik@oracle.com Cc: greg.stachnick@oracle.com; raj.alagumalai@oracle.com; ram.venkataswamy@oracle.com; ling.hao@oracle.com; shenxue.zhou@oracle.com; danny.ju@oracle.com; nadeem.aboobaker@oracle.com Subject: RE: Handling of existing values when a property is disabled Generally speaking I think there's benefit to holding onto user input for situations like this, as long as it's clearly evident that the values are not in effect. In other situations, such as a dialog, the latter goal is easier to acheive. It's probably even a simple task for editors that rely less directly on the DOM for the model, but that seems like a good architectural decision for the DD editors. It's clearly less than ideal that the not-currently-in-effect values are visible in source. But unless we can think of some other way to hold onto these without placing them into the document, it appears we'll have to trade off one benefit for the other. I think the greater of two evils may be the potential confusion of seeing discarded values still showing up in source, even if temporarily so. Tossing the values is maybe somehat annoying, but is understandable and possibly even expected by a lot of users. So I'd probably go with changing the current behavior unless someone has a deus ex machina to spring on us. -Troy ________________________________________ From: Konstantin Komissarchik Sent: Thursday, June 03, 2010 4:13 PM To: Troy Beecroft Cc: Greg Stachnick; Raj Alagumalai; Kodandaraman Venkataswamy; Ling Hui Hao; Shenxue Zhou; Zhijun Ju; Nadeem Aboobaker Subject: Handling of existing values when a property is disabled Troy, We have a UI/Usability issue that we need your input on. The question is what should the behavior be in the deployment descriptor editors when a certain user action causes some set of properties to be disabled. In particular, should we retain the values in properties that are disabled or should those properties be cleared? We’ve talked about this before and the decision at that time was to leave those properties alone as the user might want to come back to them, but perhaps it’s time to revisit that decision. Maybe we need a more in-depth guideline on this as I suspect that “natural” user expectation might vary between different types of cases. Some cases to consider: 1. Boolean property (checkbox) enabling/disabling some properties. For an example of this, see FastSwap in web or ear descriptor. 2. Enum property (radio button group or combo) presenting different sets of properties depending on selection. For an example of this, see General->Logging in web descriptor. There are other cases when user actions cause properties to be disabled, but these are the most common patterns. Thanks, - Konstantin |