> 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'.
I would agree with Wim that MWizardPage might not be necessary. MPart appears at the moment sufficient. I also like the idea of re-using MPartStack for the wizard. 2013/10/9 Eric Moffatt <[email protected]> > 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 > > > [image: Inactive hide details for Tom Schindl ---10/09/2013 09:15:51 > AM---Not strictly speaking but maybe we need some extra attributes]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 <[email protected]> > > To: > > > [email protected], > > 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: > > > [email protected] > ------------------------------ > > > > 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 <[email protected] > > <mailto:[email protected] <[email protected]>>> > 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 <[email protected] > > <mailto:[email protected] <[email protected]>> < > mailto:[email protected] <[email protected]> > > <mailto:[email protected] <[email protected]>>>> > > > > > > Having dialogs and wizards in the model would definitely be > more > > > consistent IMHO. > > > > > > Am 09.10.2013 11:50 schrieb "Tom Schindl" > > > <[email protected] > > <mailto:[email protected] <[email protected]>> > > <mailto:[email protected] <[email protected]> > > <mailto:[email protected] <[email protected]> > >>>: > > > > > > 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 > > > [email protected] > > <mailto:[email protected]<[email protected]> > > > > <mailto:[email protected] <[email protected]> < > mailto:[email protected] <[email protected]>>> > > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > > > > > _______________________________________________ > > > e4-dev mailing list > > > [email protected] <mailto:[email protected]<[email protected]> > > > > <mailto:[email protected] <[email protected]> < > mailto:[email protected] <[email protected]>>> > > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > > > > > > > > > > > -- > > > Mail: [email protected] > > <mailto:[email protected]<[email protected]> > > > > <mailto:[email protected] <[email protected]> < > mailto:[email protected] <[email protected]>>> > > > Web: http://www.teufel.net > > > > > > > > > _______________________________________________ > > > e4-dev mailing list > > > [email protected] <mailto:[email protected] <[email protected]> > > > > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > > > _______________________________________________ > > e4-dev mailing list > > [email protected] <mailto:[email protected] <[email protected]>> > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > > > > > > _______________________________________________ > > e4-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > >
<<ecblank.gif>>
<<graycol.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
