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
