Send dsdp-tm-dev mailing list submissions to
dsdp-tm-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
or, via email, send a message with subject or body 'help' to
dsdp-tm-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
dsdp-tm-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dsdp-tm-dev digest..."
Today's Topics:
1. RSEDefaultNewConnectionWizardMainPage seems to be more
specific than intended (Jacques Arnoux)
2. RE: RSEDefaultNewConnectionWizardMainPage seems to be more
specific than intended (Stieber, Uwe)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Mar 2010 00:37:18 -0400
From: Jacques Arnoux <jacques.arnoux@xxxxxxxxxx>
Subject: [dsdp-tm-dev] RSEDefaultNewConnectionWizardMainPage seems to
be more specific than intended
To: dsdp-tm-dev@xxxxxxxxxxx
Message-ID: <4BB17FFE.2020606@xxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I'm currently trying to implement a NewConnectionWizard that extends
RSEAbstractNewConnectionWizard and uses
RSEDefaultNewConnectionWizardMainPage as a main page.
While typing a hostname into the host name field, I encountered a stack
overflow I figured out as follow:
while trying to *validate the form*/text typed and refresh the buttons
(RSEDefaultNewConnectionWizardMainPage[:154].canFlipToNextPage()), the
mainPage checks whether mainPage is a RSEDefaultNewConnectionWizard or not.
If not (my case), is calls super.canFlipToNextPage() which in turn seems
to ask to the implementation to *validate the form*, etc, etc...
Isn't RSEDefaultNewConnectionWizardMainPage usable without
RSEDefaultNewConnectionWizard?
My workaround is to extend RSEDefaultNewConnectionWizard instead of
RSEAbstractNewConnectionWizard but it's not so great cause I cannot even
use the super attributes since there is no getters and setters and my
code differs in only performFinish(). I have to override everything.
Is this intended and am I missing something here?
Thanks,
Jac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/dsdp-tm-dev/attachments/20100330/7d44032c/attachment.html
------------------------------
Message: 2
Date: Tue, 30 Mar 2010 10:33:25 +0200
From: "Stieber, Uwe" <Uwe.Stieber@xxxxxxxxxxxxx>
Subject: RE: [dsdp-tm-dev] RSEDefaultNewConnectionWizardMainPage seems
to be more specific than intended
To: "Target Management developer discussions"
<dsdp-tm-dev@xxxxxxxxxxx>
Message-ID:
<F7CF6DC5B863B94BA58A030D02DCD9F4854E7F@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Hi Jacques,
Well, the RSEDefaultNewConnectionWizardMainPage is (weak) bound to
RSEDefaultNewConnectionWizard, as the RSEDefaultNewConnectionWizard is
implementing the RSE wizard specific/typical behavior.
RSEAbstractNewConnectionWizard is provided as common base class to allow
for 3rd party wizards following a complete different idea than the
default RSE wizards and more specifically, do not share UI with the RSE
default wizards.
Nonetheless, RSEDefaultNewConnectionWizardMainPage should be usable even
with a non RSEDefaultNewConnectionWizard implementation. For that
purpose, the RSEDefaultNewConnectionWizardMainPage forwards to the super
implementation.
(RSEDefaultNewConnectionWizardMainPage[:154].canFlipToNextPage
()), the mainPage checks whether mainPage is a
RSEDefaultNewConnectionWizard or not.
To be precise, the main page determines the associated wizard and checks
if the wizard is of type RSEDefaultNewConnectionWizard or not.
If not (my case), is calls super.canFlipToNextPage() which in
turn seems to ask to the implementation to validate the form,
etc, etc...
Well, the super.canFlipToNextPage(), calls for "isPageComplete()", which
is overwriten in RSEDefaultNewConnectionWizardPage to forward the call
to the form, and "getNextPage()" which is using the same check as the
"canFlipToNextPage()". The form itself, which the two invoked methods
"isPageComplete()" and "isConnectionUnique()" does not go back to the
page to trigger a "canFlipToNextPage()" again. At least I cannot see how
from the code. You may educate me by forwarding a short extract from the
stack overflow error stack traces (run Eclipse with -Xint if you don't
have a stack trace visible for the error). Probably it is the
"getNextPage()" implementation of the wizard which is getting back to
the page?
Thanks, Best regards,
Uwe Stieber
-----Original Message-----
From: dsdp-tm-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Jacques Arnoux
Sent: Tuesday, March 30, 2010 6:37 AM
To: dsdp-tm-dev@xxxxxxxxxxx
Subject: [dsdp-tm-dev] RSEDefaultNewConnectionWizardMainPage
seems to be more specific than intended
Hi all,
I'm currently trying to implement a NewConnectionWizard that
extends RSEAbstractNewConnectionWizard and uses
RSEDefaultNewConnectionWizardMainPage as a main page.
While typing a hostname into the host name field, I
encountered a stack overflow I figured out as follow:
while trying to validate the form/text typed and refresh the
buttons
(RSEDefaultNewConnectionWizardMainPage[:154].canFlipToNextPage
()), the mainPage checks whether mainPage is a
RSEDefaultNewConnectionWizard or not.
If not (my case), is calls super.canFlipToNextPage() which in
turn seems to ask to the implementation to validate the form,
etc, etc...
Isn't RSEDefaultNewConnectionWizardMainPage usable without
RSEDefaultNewConnectionWizard?
My workaround is to extend RSEDefaultNewConnectionWizard
instead of RSEAbstractNewConnectionWizard but it's not so
great cause I cannot even use the super attributes since
there is no getters and setters and my code differs in only
performFinish(). I have to override everything.
Is this intended and am I missing something here?
Thanks,
Jac
------------------------------
_______________________________________________
dsdp-tm-dev mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
End of dsdp-tm-dev Digest, Vol 56, Issue 5
******************************************