Re: [e4-dev] Now's the time to figure out what we need in e4

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

Modeling the Dialogs and Wizards for an application is a good thing to do. If you consider the model to represent the agnostic description of what UI bits the app needs in order to function then it makes perfect sense to say something along the lines of:

"My Contacts app needs the Contacts window, an Open Contact List dialog and a Create Contact wizard"

This is a proper indication to anybody wishing to implement that application on *any* platform they they'll need to supply the rendered UI for those components.

Before getting into the model specifics I'd like to look at what Dialogs and Wizards *are*...

- They show up in their own windows
- They both represent requests to gather information from the User
- They're transient; opened by the IDE -> closed by the User

So, the specifics of how they're modeled aside, how do the elements communicate the results back to the IDE ? The pattern for creation seems fairly straightforward; add all necessary input parameters into the 'localContext' used to render the Dialog / Wizard. It's less clear how the IDE (app) then retrieves the result.

For the model itself how about both MDialog & MWizard extend MWindow (since they show up as windows). Whether or not we also need the MWizard to have a specific collection of MWizardPages or if we can just have the logic manipulate an MPartStack using ids is open for me, there's are good reasons for either way. The MApplication would be extended to have two new collections; 'dialogs' and 'wizards'.

Note that there's a beneficial side-effect of modeling the Dialogs / Wizards; this structure makes it completely natural to embed parts into both Dialogs and Wizard(page)s. One of the initial problems I faced during my demos for this was that I had to 'fake' the embedded part being in the model (see EModelService#hostElement); if the MDialog were modeled this would no longer be an issue.

Thanks folks, this is exactly the type of discussion I was hoping for,
Eric


Tom Schindl ---10/09/2013 09:15:51 AM---Not strictly speaking but maybe we need some extra attributes later on there so I would model it exp

From:	Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
To:	e4-dev@xxxxxxxxxxx,
Date:	10/09/2013 09:15 AM
Subject:	Re: [e4-dev] Now's the time to figure out what we need in e4
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

Not strictly speaking but maybe we need some extra attributes later on
there so I would model it explicitly.

Rethink my proposal would change to:

MWizard extend MElementContainer<MWizardPage> {

}

MWizardPage extends MPart {

}

For MDialog we could also think of

MDialog {
   MPart part
}

which is probably better alignment with a MWizard then.

Tom

On 09.10.13 15:03, Wim Jongman wrote:
> I think a MWizard is an excellent idea but do we need MWizardPages?
> Having wizard pages is specific to an implementation of a wizard. 
> 
> Cheers,
> 
> Wim
> 
> 
> On Wed, Oct 9, 2013 at 2:50 PM, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx
> <mailto:tom.schindl@xxxxxxxxxxxxxxx>> wrote:
> 
>     The concept is universal and has nothing to do with SWT / JFace.
> 
>     MDialog extends MPart {
> 
>     }
> 
>     MWizard extends MElementContainer<MWizardPage> {
> 
>     }
> 
>     MWizardPage {
> 
>     }
> 
>     MPart extends MWizardPage, .... {
> 
>     }
> 
>     Hack you could even see a wizard to be a specialication of
>     MPartStackContainer!
> 
>     Tom
> 
>     On 09.10.13 14:40, Marc Teufel wrote:
>     > Are you sure that this is really more consistent ? Dont forget:
>     Wizards
>     > for instance are a JFace-specific kind of thing and i always
>     thought the
>     > application model itself should be independent of SWT, JFace. Or
>     do you
>     > think of a more abstract way of integration and if yes how this could
>     > look like?
>     >
>     >
>     > 2013/10/9 Lars Vogel <lars.vogel@xxxxxxxxx
>     <mailto:lars.vogel@xxxxxxxxx> <mailto:lars.vogel@xxxxxxxxx
>     <mailto:lars.vogel@xxxxxxxxx>>>
>     >
>     >     Having dialogs and wizards in the model would definitely be more
>     >     consistent IMHO.
>     >
>     >     Am 09.10.2013 11:50 schrieb "Tom Schindl"
>     >     <tom.schindl@xxxxxxxxxxxxxxx
>     <mailto:tom.schindl@xxxxxxxxxxxxxxx>
>     <mailto:tom.schindl@xxxxxxxxxxxxxxx
>     <mailto:tom.schindl@xxxxxxxxxxxxxxx>>>:
>     >
>     >         On 07.10.13 16:50, Markus A. Kuppe wrote:
>     >         > On 10/07/2013 04:37 PM, Lars Vogel wrote:
>     >         >> I personally think the lack of Pojo programming support for
>     >         the Eclipse IDE
>     >         >> is preventing a larger ecosystem to provide Eclipse 4
>     >         extensions. So your
>     >         >> work started for POJO views in
>     >         >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=356511 was
>     >         really great.
>     >         >> Having the same of handlers would help. Maybe it could be
>     >         used to build a
>     >         >> perspective switcher which works in the IDE and the RCP
>     >         applications.
>     >         >
>     >         > Hi,
>     >         >
>     >         > the same goes for PreferencePages. Ideally, the preference
>     >         page extesion
>     >         > point ("org.eclipse.ui.preferencePages") would accept POJOs
>     >         and not just
>     >         > instances implementing
>     >          org.eclipse.ui.IWorkbenchPreferencePage (similar
>     >         > to bug #356511).
>     >
>     >         Before doing this I'd like us to discuss in more general
>     if Dialog &
>     >         Wizards should not get part of the model!
>     >
>     >         Tom
>     >         _______________________________________________
>     >         e4-dev mailing list
>     >         e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
>     <mailto:e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>>
>     >         https://dev.eclipse.org/mailman/listinfo/e4-dev
>     >
>     >
>     >     _______________________________________________
>     >     e4-dev mailing list
>     >     e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
>     <mailto:e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>>
>     >     https://dev.eclipse.org/mailman/listinfo/e4-dev
>     >
>     >
>     >
>     >
>     > --
>     > Mail: teufel.marc@xxxxxxxxx <mailto:teufel.marc@xxxxxxxxx>
>     <mailto:teufel.marc@xxxxxxxxx <mailto:teufel.marc@xxxxxxxxx>>
>     > Web: http://www.teufel.net
>     >
>     >
>     > _______________________________________________
>     > e4-dev mailing list
>     > e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
>     > https://dev.eclipse.org/mailman/listinfo/e4-dev
>     >
> 
>     _______________________________________________
>     e4-dev mailing list
>     e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
>     https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
> 
> 
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 

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