Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] Question about AbstractRemoteResourceManagerConfigurationWizardPage.createContents

Dave,

I meant the hook would be called when creating the preference page
widgets.  The abstract class would call the hook while or just after
contributing its own widgets, in order for derived classes to supply
code that would **continue** to contribute widgets to the parent
Composite.  Your code would get called **as** the abstract class goes
about building the widget portion of the preference page.

Does that clear up what I said?

R^2

On Tue, 2007-08-28 at 12:39 -0400, Dave Wootton wrote:
> Randy
> That's the problem I was trying to solve by changing the definition of 
> createControl in AbstractRemotePreferencePage to return Composite instead 
> of Control. Now that I follow the type hierarchy upward, I see that is not 
> possible since the PreferencePage class imposes that definition.
> 
> An accessor method would be reasonable for me. Since I'm a not-quite OO 
> Java developer, is there a reason that the accessor method in 
> AbstractRemotePreferencePage would need to be an abstract method? I would 
> have approached this by defining a concrete method in that class, 
> something like 'protected Composite getContentPane()' that returned the 
> top-level Composite created by createControl(), and where that Composite 
> is a private class variable instead of being local to createControl. It 
> seems if I define that method as abstract, then I have the same problem I 
> have now, where I would need to assume implementation details of 
> AbstractRemotePreferencePage when implementing the concrete method in my 
> class.
> 
> Thanks
> Dave
> 
> 
> 
> "Randy M. Roberts" <rsqrd@xxxxxxxx> 
> Sent by: ptp-dev-bounces@xxxxxxxxxxx
> 08/28/2007 12:12 PM
> Please respond to
> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> 
> 
> To
> ptp-dev <ptp-dev@xxxxxxxxxxx>
> cc
> 
> Subject
> Re: [ptp-dev] Question about 
> AbstractRemoteResourceManagerConfigurationWizardPage.createContents
> 
> 
> 
> 
> 
> 
> Dave,
> 
> IMHO, I would not cast a Control to a Composite.  That may work today,
> but who knows about the future.  I would put in some well-defined 
> abstract method as a hook into the abstract class for your use.
> 
> On another subject...  Shouldn't the UI stuff in org.eclipse.ptp.remote
> be put in its own plugin, org.eclipse.ptp.remote.ui?  That's where
> I would put the AbstractRemotePreferencePage, and other stuff like
> that.
> 
> Just my 1.99995 cents worth.
> 
> R^2
> 
> On Tue, 2007-08-28 at 11:02 -0400, Dave Wootton wrote:
> > I was looking at how I could set default proxy options in my PE 
> preference 
> > page which extends AbstractRemotePreferencePage. I discovered that the 
> > createContents method in AbstractRemotePreferencePage returns the 
> > Composite that is the parent of all widgets in the preference page.
> > 
> > I realized that if I called 'super.createContents()' from my 
> > createContents method, that I could then add additional widgets to the 
> > preference page, below the widgets created by 
> > AbstractRemotePreferencePage.
> > 
> > The one catch in this is that 
> AbstractRemotePreferencePage.createContents 
> > returns a Control object rather than a Composite object. Although a bit 
> > risky, if I cast it to Composite class, then I get what I want.
> > 
> > Is it possible to change this method so it returns Composite instead of 
> > Control?
> > 
> > Also, if 
> > AbstractRemoteResourceManagerConfigurationWizardPage.createContents was 
> > changed to a protected method returning Composite instead of void, then 
> > additional widgets could be added to the wizard page, instead of 
> requiring 
> > a separate wizard page for additional options (although I will keep the 
> > 2nd wizard page). Would this potentially cause problems with the 
> > createControl method in that class?
> > 
> > Dave
> > 
> > 
> > 
> > Dave Wootton/Poughkeepsie/IBM@IBMUS 
> > Sent by: ptp-dev-bounces@xxxxxxxxxxx
> > 08/28/2007 09:52 AM
> > 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] Question about 
> > AbstractRemoteResourceManagerConfigurationWizardPage.createContents
> > 
> > 
> > 
> > 
> > 
> > 
> > Thanks Randy.
> > I just submitted a patch for this as bug 201422. I forgot to re-sync to 
> > HEAD before coding the change. Hopefully this doesn't interfere with any 
> 
> > other work going on in org.eclipse.ptp.remote. If I nee to rework this 
> > patch, let me know.
> > 
> > Dave
> > 
> > 
> > 
> > "Randy M. Roberts" <rsqrd@xxxxxxxx> 
> > Sent by: ptp-dev-bounces@xxxxxxxxxxx
> > 08/27/2007 03:33 PM
> > Please respond to
> > Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> > 
> > 
> > To
> > ptp-dev <ptp-dev@xxxxxxxxxxx>
> > cc
> > 
> > Subject
> > Re: [ptp-dev] Question about 
> > AbstractRemoteResourceManagerConfigurationWizardPage.createContents
> > 
> > 
> > 
> > 
> > 
> > 
> > Dave, Greg,
> > 
> > I'm glad to see that the multiple pages functionality came
> > in handy!
> > 
> > R^2
> > 
> > On Mon, 2007-08-27 at 14:38 -0400, Greg Watson wrote:
> > > Ok, that sounds great. I'm always happy not to have to do any 
> > > additional work. :-)
> > > 
> > > Greg
> > > 
> > > On Aug 27, 2007, at 12:04 PM, Dave Wootton wrote:
> > > 
> > > > Greg
> > > > I don't think I need an extension point to do this.  I have a class,
> > > > PEResourceManagerConfigurationWizardPageFactory which is a clone of
> > > > ORTEResourceManagerConfigurationWizardPageFactory. There's a 
> > > > getPages()
> > > > method in this class which returns an array of 
> > > > RMConfigurationWizardPage
> > > > objects. If I change the implementation of this method to create an 
> > > > array
> > > > with two objects, the first being an instance of
> > > > PEResourceManagerConfigurationWizardPage and the second my new 
> > > > wizard page
> > > > class, then when I go thru the wizard, I see the two pages in 
> > > > order. I've
> > > > started coding my second wizard page and it so far it looks like 
> this
> > > > works. There's code somewhere in  a superclass that seems to 
> > > > iterate thru
> > > > this array displaying pages in the proper order.
> > > >
> > > > If this is a reasonable way to implement this, then I don't think I 
> > > > need
> > > > any modifications to other PTP code.
> > > > Dave
> > > >
> > > >
> > > >
> > > > Greg Watson <g.watson@xxxxxxxxxxxx>
> > > > Sent by: ptp-dev-bounces@xxxxxxxxxxx
> > > > 08/27/2007 11:37 AM
> > > > 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] Question about
> > > > AbstractRemoteResourceManagerConfigurationWizardPage.createContents
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Dave,
> > > >
> > > > So to get this straight, the idea would be to provide an extension
> > > > point that would let you specify your own page. The page display
> > > > order would be:
> > > >
> > > > Choose RM Type -> Proxy Configuration -> RM specific page (if
> > > > present) -> RM Name & Description
> > > >
> > > > Does that sound ok?
> > > >
> > > > Greg
> > > >
> > > > On Aug 27, 2007, at 10:56 AM, Dave Wootton wrote:
> > > >
> > > >> Greg
> > > >> I'm looking at the wizard panels again, and it looks like it may
> > > >> not make
> > > >> sense to extend the AbstractRemoteManagerConfigurationWizardPage 
> > > >> class
> > > >> since I think this means that we need to duplicate the GUI logic to
> > > >> manage
> > > >> all the widgets related to proxy setup and remote access in that
> > > >> class as
> > > >> well as adding our additional options for proxy invocation.
> > > >>
> > > >> I'm thinking that we would just use that class directly, then
> > > >> implement a
> > > >> second proxy setup page, extending from RMConfigurationWizardPage
> > > >> where we
> > > >> would implement the logic to manage our proxy invocation options.
> > > >> This way
> > > >> we don't have problems staying in sync with
> > > >> AbstractRemoteManagerConfigurationWizardPage. It looks like the 
> proxy
> > > >> configuration wizard is already set up to support this concept by 
> the
> > > >> creation of an array with two elements, the
> > > >> AbstractRemoteManagerConfigurationWizardPage class followed by the 
> > > >> new
> > > >> wizard page in
> > > >> PEResourceManagerConfigurationWizardPageFactory.getPages().
> > > >>
> > > >> Does this make sense?
> > > >>
> > > >> I guess the other alternative would be to create a pane in the
> > > >> createContents() method of
> > > >> AbstractRemoteManagerConfigurationWizardPage
> > > >> that we can access and create our additional widgets in that pane.
> > > >> Dave
> > > >> ----- Forwarded by Dave Wootton/Poughkeepsie/IBM on 08/27/2007
> > > >> 10:37 AM
> > > >> -----
> > > >>
> > > >> Dave Wootton/Poughkeepsie/IBM
> > > >> 08/08/2007 11:54 AM
> > > >>
> > > >> To
> > > >> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> > > >> cc
> > > >>
> > > >> Subject
> > > >> Re: [ptp-dev] Question about
> > > >> AbstractRemoteResourceManagerConfigurationWizardPage.createContents
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Greg
> > > >> Rolf and I talked about this and think our extending this class to
> > > >> add the
> > > >> widgets for resource manager-unique options would be reasonable. I
> > > >> think
> > > >> this means defining some key we can use to store the options tring
> > > >> as well
> > > >> as a way to get/set it.
> > > >> Dave
> > > >>
> > > >>
> > > >>
> > > >> Greg Watson <g.watson@xxxxxxxxxxxx>
> > > >> Sent by: ptp-dev-bounces@xxxxxxxxxxx
> > > >> 08/07/2007 01:06 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] Question about
> > > >> AbstractRemoteResourceManagerConfigurationWizardPage.createContents
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> I was just going to change that to 'Launch server manually'. :-)
> > > >>
> > > >> I didn't have any particular solution in mind. If you'd like to be
> > > >> able to override the default implementation to provide your own
> > > >> wizard page then that would probably be easiest for me. It could 
> get
> > > >> a bit messy trying to provide enough flexibility on the current 
> page
> > > >> for every implementation.
> > > >>
> > > >> Greg
> > > >>
> > > >> On Aug 7, 2007, at 12:25 PM, Dave Wootton wrote:
> > > >>
> > > >>> When the second page of the resource wizard appears, there is text
> > > >>> at the
> > > >>> bottom of the page next to a checkbox stating Launch ORTE server
> > > >>> manually,
> > > >>> where ORTE should be able to be replaced by PE, LoadLeveler, etc.
> > > >>> We could
> > > >>> implement our own wizard page extending this class to fix this, 
> but
> > > >>> that
> > > >>> seems like the wrong thing to do to fix a message string. However,
> > > >>> we have
> > > >>> had some discussion about additional fields on this page for 
> > > >>> resource
> > > >>> manager invocation options, such as run mode for the proxy (PE
> > > >>> with or
> > > >>> without LoadLeveler), turning on an internal proxy trace, etc.
> > > >>> Is the intent to provide a generic wizard creation page that 
> > > >>> includes
> > > >>> fields for proxy options, or would we be expected to provide our 
> own
> > > >>> implementation, which might be a little more user-friendly since 
> we
> > > >>> could
> > > >>> provide more appropriate widgets for specifying the options.
> > > >>>
> > > >>> Either way is fine, we just don't want to have more unique panels
> > > >>> than we
> > > >>> really need.
> > > >>>
> > > >>> Thanks
> > > >>> 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
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > 
> > 
> > _______________________________________________
> > 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



Back to the top