| Re: [ptp-dev] Additional proxy options field in proxy wizard |
Greg I don't expect users to change options frequently. I expect them to set the options up when creating a new resource manager, then pretty much leave them alone. If there was a problem where they needed to turn on a proxy trace or change the polling frequency for LoadLeveler, then they I think they would change the options for an existing proxy. A button like you have in your screen capture might work as long as there was only a single options panel, which I expect would be the case for PE and LoadLeveler. I would label the button proxy options or something like that since advanced doesn't make me think of setting proxy options. If you think this is the way to solve it, I could make the changes for my PE plugin after I get my current code approved and committed since that code is currently in legal review and I shouldn't be making extensive changes to it now. Dave Greg Watson <g.watson@xxxxxxxxxxxx> Sent by: ptp-dev-bounces@xxxxxxxxxxx 01/16/2008 09:57 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 Dave, Are users likely to be changing options very often? One thing that might work is to replace the "Extra proxy arguments" field with an Advanced... button that would open a dialog provided by the RM implementation. See attached screen shot. Would that work for you? Greg On Jan 16, 2008, at 3:39 PM, Dave Wootton wrote: > 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 > > > _______________________________________________ > 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
Attachment:
ss.tiff
Description: TIFF image