> For background there *are* identifiable advantages to incorporating Dialogs...into the model. Mostly this revolves around allowing the dialog to hook into the MApplication's context chain (allowing DI > & service access...) as well as normalizing the hosting of MParts in the dialog.
I can confirm that, in our Eclipse 4 training sessions I felt that using Dialogs and Wizards was a step back because DI could not be used directly. Best regards, Lars 2013/11/20 Eric Moffatt <[email protected]> > JD, this is the reason that we're starting with only the barest of > enhancements; we're waiting to see concrete uses before deciding whether or > not any other extensions are needed (or indeed if even the new ones are). > We realize that we could likely accomplish everything using tags but think > that having the model elements available will make it easier for clients to > more accurately define their application (and for others to more easily > understand what's in the app). > > For background there *are* identifiable advantages to incorporating > Dialogs...into the model. Mostly this revolves around allowing the dialog > to hook into the MApplication's context chain (allowing DI & service > access...) as well as normalizing the hosting of MParts in the dialog. > > Eric > > > [image: Inactive hide details for Joseph D Carroll Jr ---11/18/2013 > 06:00:02 PM---I realize these changes are already in master, but I]Joseph > D Carroll Jr ---11/18/2013 06:00:02 PM---I realize these changes are > already in master, but I think we are getting too specific with our mode > > > > From: > > > Joseph D Carroll Jr <[email protected]> > > To: > > > E4 Project developer mailing list <[email protected]>, > > Date: > > > 11/18/2013 06:00 PM > > Subject: > > > Re: [e4-dev] Model changes for 4.4 M4 > > Sent by: > > > [email protected] > ------------------------------ > > > > I realize these changes are already in master, but I think we are getting > too specific with our model. Having an MWizardDialog only opens the door > to having an MWizardPart and IMHO that defeats the entire purpose of having > a generic model in the first place. > > If we are going to model the Wizard (which I can make arguments either > way) it should inherit from MPart if anything. I guess I am more for > modeling Wizards AND WizardPages because I feel that makes a better > argument for reuse. But all of this is for naught if we are going to > delineate our model so rigidly. > > I would even be for creating a model element that blurs the line between > WizardPage and PreferencePage (call it an MInteractionPage). Because, from > an abstract sense, WizardPage and PreferencePage accomplish the same thing; > taking some form of user interaction. Combine that with the existing DI > framework and there is no need to have separate entities. > > So I would vote: > -1 on MWizardDialog > 0 on MDialog > I think we can enhance our existing tags on MWindow to accomplish > everything the Dialog does (like even having a "dialog" tag). > > JD > > > On Tue, Nov 12, 2013 at 1:44 PM, Paul Elder > <*[email protected]*<[email protected]>> > wrote: > > Brian de Alwis <*[email protected]* <[email protected]>> > wrote on 11/11/2013 12:17:29 PM: > > > > > > I’d have thought we wanted MDialog to be distinct from MWindow? And > > aren’t wizards really a form of dialog? > > > > > The Workbench code (currently) assumes that it can take over and > > manage any MWindow. I don’t think we want the workbench to manage > dialogs :-) > > > > For the first cut, I'm going to create MDialog (subclassing MWindow), > and MWizardDialog subclassing MDialog. If subclassing MWindow proves to be > a problem, we can change it, but logically (at least on the windowing > systems I know of), a dialog is a window. > > Paul > _______________________________________________ > e4-dev mailing list > *[email protected]* <[email protected]> > *https://dev.eclipse.org/mailman/listinfo/e4-dev*<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 > >
<<graycol.gif>>
<<ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
