Re: [ptp-dev] Additional proxy options field in proxy wizard

[Dave Wootton <dwootton@xxxxxxxxxx>]

Greg
The IBMLLResourceManagerOptionWizardPage class needs work to properly save 
and restore options. We realized that the general support in PTP existed 
for editing resource manager configurations only after Rolf had packaged 
up his LoadLeveler plugin. The work for this class to properly save and 
restore options is on a todo list.

My PEResourceManagerOptionWizardPage class now properly saves and restores 
both configuration options and saves the invocation options string. 

When a brand new resource manager configuration is created, my 
PEResourceManagerFactory class now obtains the values from the PTP PE 
preferences and stores then in a PEResourceManagerConfiguration object (in 
the createConfiguration method). When the createControl method in my 
PEResourceManagerOptionWizardPage class is invoked, the fiellds in that 
wizard page are filled in from the PEResourceManagerConfiguration object. 
The very first time the wizard is run for a PEResourceManagerConfiguration 
object, the values filled in will be the values obtained from the 
preferences. When an existing PEResourceManagerConfiguration object is 
edited, the values obtained from the PEResourceManagerConfiguration will 
be the values saved in that configuration in a previous edit. I do not 
look at the invocation options string at all in createControl(). 

When performOk in PEResourceManagerOptionWizardPage is called, I do three 
things. First, I validate fields that require validation. Once a field is 
validated, I store its value into the configuration object, and I append 
the option (option/value pair) to the invocation options string. Once I've 
processed all fields, I set the invocation options string in the resource 
manager configuration by calling setInvocationOptions.

Now that I look at this again, maybe storing the save option twice, once 
as a unique field in the resource manager configuration and again as part 
of the invocation options string isn't such a good idea. I suppose I could 
fix PEResourceManagerFactory to build an invocation options string using 
the preference values, change createControl to get and parse the 
invocation options string to fill in the individual fields in the wizard 
page, and just build the invocation options string in performOk. I guess I 
would also need to deal with dealing with the options invocation string 
after the page has been initialized somewhere (updateConfigOptions no 
longer exists in my class. If I remember correctly, after syncing with 
changes in PTP code, that processing all happens now in performOk). 
Parsing invocation options shouldn't be difficult since it is a string of 
blank-delimited options that are either boolean options or 
'--option=value' strings.

If I do this, then it may not be so important that the invocation options 
string on the first widget page should be hidden or read-only from the 
perspective of users entering values and having them ignored. Allowing the 
user to change the options string on the first page, and then presenting 
the same options again in the second page as separate widgets could be 
confusing to a user until the user figures out what the interaction 
between the two wizard pages is. Even as a read only field, the invocation 
options might be confusing to a user, who may wonder why they are there 
and why they are read only. I think the best solution from a usability 
viewpoint is to hide the options, but if that's a real problem, then 
making them read-only is ok with me.

Dave



Greg Watson <g.watson@xxxxxxxxxxxx> 
Sent by: ptp-dev-bounces@xxxxxxxxxxx
01/15/2008 07:04 PM
Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>


To
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc

Subject
Re: [ptp-dev] Additional proxy options field in proxy wizard






Hi Dave,

Actually, the options are getting saved. What is happening is that 
when the wizard is first created (when you edit an RM configuration 
for example), all the wizard pages are also created. This calls 
createControl in IBMLLResourceManagerOptionWizardPage. Each time you 
create an EventMonitor or set the value of a text widget, 
updateConfigOptions is getting called. Since none of the widgets in 
the control have been initialized, the constructed options string is 
empty when setInvocationOptions gets called in updateConfigOptions. 
Now when the first wizard page is finally displayed, it reads the 
value of the invocation options from the config which has been set to 
the empty string. If you prevent the call to updateConfigOptions until 
the wizard page has been initialized (such as with a "loading" flag), 
then the problem should be fixed.

As to the second question. How do you save and restore the proxy 
options now without parsing them? If the user edits the configuration, 
do you restore the values in your wizard page? If you parse the option 
string, then the extra proxy options field should show the user what 
options are going to be passed to the proxy, and then could be 
customized manually further by editing this field. If you store the 
options separately, then you could just re-generate the options string 
when the user saves the configuration. The extra proxy options field 
would still show what is going to be passed to the proxy, but any 
changes to this field would be lost.

If you'd really don't like the field being editable then I could 
provide the ability to make it read-only so it just displays whatever 
options have been set elsewhere (or a checkbox to enable it for 
editing). It's tricky to make fields optional, so I'd rather not go 
that route. But I'm willing to be convinced.

Greg

On Jan 15, 2008, at 12:32 PM, Dave Wootton wrote:

> I updated to the latest code this morning and found that the
> AbstractRemoteResourceConfigurationWizardPage class has a field for 
> proxy
> invocation options. For my PE proxy and Rolf's LoadLeveler proxy, we
> implemented a class for an additional wizard page where these 
> options are
> set by filling in/checking values in individual widgets to make the 
> step a
> little more friendly.
>
> When I double click a resource manager to edit its configuration, the
> first panel has the proxy invocation options in the invocation options
> field. If I change them and click finish, they don't get saved. I 
> have to
> change the values on my panel (the second wizard page in my case) and
> click finish there, and those values get saved. So in my case, the 
> proxy
> invocation options on the first panel are display-only and are not 
> saved.
>
> Is it possible to change the 
> AbstractRemoteResourceConfigurationWizardPage
> class so that the proxy invocation options field is optional, maybe 
> by a
> flag on the constructor, or a method call that must happen before
> createControl is called, since I do extend that class in my
> PEResourceManagerWizardConfigurationPage?
>
> I could duplicate at least the createContents and performOk methods 
> and
> delete the code dealing with the proxy invocation options field, but 
> that
> doesn't seem like the right way to handle this.
>
> The only othre possibility I see, which I'm not sure is the right 
> thing
> either, is that when my second wizard page is displayed, parse the 
> proxy
> invocation options string filled in in the first panel and populate 
> the
> widgets in my second wizard page with those values, or if there was no
> invocation options string, then the defaults from preferences.
>
> Suggestions?
> Dave
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev