Re: [ptp-dev] use case question regarding JAXB launch tab configuration

[Greg Watson <g.watson@xxxxxxxxxxxx>]

On May 23, 2011, at 2:06 PM, Albert L. Rossi wrote:

> Dave,
> 
> ----- Dave Wootton <dwootton@xxxxxxxxxx> wrote:
>> Al
>> The PE and probably LoadLeveler resource managers will fit case 2 as you 
>> noted. 
>> 
>> I don't think I have a reason for a non-partitioned case since I expect 
>> each attribute to appear on only one tab of the tab set. However, if there 
>> was a case where an attribute could appear on multiple tabs, I would 
>> expect that the value that was applied was the value that was set when the 
>> apply/run/profile button was clicked and not te value from a hidden tab 
>> later in the tab sequence. I'd also expect that if I changed a value in 
>> one tab and then switched to a different tab which contained the same 
>> attribute, than the value now appearing in the second tab would be 
>> identical to the value that was set in the tab I just switched from. I 
>> think it would be confusing to me if the same attribute on two tabs had 
>> different values.
> 
> Good.  I've assured this is the way it works.
> 
> 
>> 
>> I might have reason to use case 3 to support basic/advanced mode for the 
>> PE resource manager. If I was to do that, I think I would have a model 
>> where tab 'A' was non-shared and tabs 'B..E' shared. In my case I would 
>> expect that if the user had tab A visible when he hit apply/run, then only 
>> the values of the attributes from tab A would be used. If the user had one 
>> of the tabs B..E visible, then I would expect only the values from tabs 
>> B..E to be used. I think that makes the argument in favor of an explicit 
>> list of shared tabs for each tab instead of the boolean you currently 
>> have.
> 
> Great.  I'm working on it now.
> 
>> 
>> However, I am thinking I prefer to implement advanced/basic mode as two 
>> separate resource managers to make the user's choice a little more 
>> explicit than relying on what tab is currently visible when the user hits 
>> apply/run to make the decision which mode to run. Particularly since I'm 
>> concerned that the user may not remember whether the run configuration was 
>> last used in basic or advanced mode when he hits the 'run' icon to run the 
>> last selected run configuration instead of hitting 'run configurations' 
>> and making an explicit choice. So with my current thinking, I probably 
>> wouldn't use case 3.
> 
> OK.  But I agree that the option, if it exists, should be based on an explicit superset.  
> 
> If Greg gives me the go ahead with the XSD/Java binding change for this one class API, the internal changes are all in place.  I've made the changes locally and am getting ready to test it.
> 
> Thanks for the feedback,
> 
> Al

Al,

I see no problem with this change.

Greg