When I implement Dialogs these days, it is not that easy to bring it together with Dependency Injection. When a Dialog is Part of the Application Model I hope it is easy to get dependencies in the same way I can do it with a Part. Nowadays when I want to get e.g. a Service into a Dialog i have two Options:
1. Drop in the Service manually cia a Setter or the Constructor of the Dialog 2. Use ContextInjectionFactory.make When a Dialog is Part of the Application Model and if I understand the new APIs correctly I simply need to define the MDialog in my model, connect the Dialog with a Pojo-Class via its Contribution-URI and afterwards I can just do a @Inject MyService service to get the Service the standard way... I am not sure if the new MDialogs/MWizards is adressing this (I have to less informations about it actually, what Bug is it?) but this is the " problem " I personally have actually with Dialogs in my daily work. Marc 2014/1/14 Doug Schaefer <[email protected]> > I’ll ask a naïve newby question :). If we want to model dialogs and > wizards, why not go all the way down to widgets? Other than they lifecycle > of a modal window, what benefit does modelling these get you? > > Doug. > > From: Marc Teufel <[email protected]> > Reply-To: E4 Project developer mailing list <[email protected]> > Date: Tuesday, January 14, 2014 at 12:43 AM > To: E4 Project developer mailing list <[email protected]> > Subject: Re: [e4-dev] MDialog / MWizard will be removed in M5 > > Same for me here, please try keep it. I am working on a bigger business > solution based on pure e4 and I am already dealing with Dialogs (and > Wizards) so I know about the pain with them... I am interested in getting > these new features into the Luna Release because I hope things are getting > easier by integrating Dialogs and Wizards into the Application Model. If > you are interested, I can offer to test/implement the new API in my > solution. The only problem I actually have is, i don't know where to start. > Is there any documentation of the new API, Wikipages, Samples or atleast > Unit-Tests where I can see how the new elements have to be used. Also > interesting: Does the Application Model Editor already support > theenhancements or do I have to write the XML manually by myself ? > > Greetings, Marc. > > > > > 2014/1/13 Paweł Doleciński <[email protected]> > >> Hi folks, >> >> please do not do it! Wizards in model is what I was waiting for. We've >> got a real use case for it, as we need to model workflows. Wizard seems to >> be a perfect solution for us, especially if you can model it and display as >> a part. >> >> Perhaps, if you could wait a bit more we might present an use case and >> general solution based on our special case. Maybe someone would be >> interested. >> >> Cheers, >> Paweł. >> >> -- >> Pozdrawiam / Best regards >> Paweł Doleciński >> >> >> On 13 January 2014 21:58, Tom Schindl <[email protected]>wrote: >> >>> What is the maximum timeframe? I really want to keep them and make use >>> of them in my javafx port! >>> >>> Cann't we mark them as experimental? >>> >>> Tom >>> >>> Von meinem iPhone gesendet >>> >>> Am 13.01.2014 um 21:22 schrieb Eric Moffatt <[email protected]>: >>> >>> Folks, since we've received no relevant feedback on using these new >>> model elements we anticipate removing them for Luna. The model should only >>> contain elements for which there is a clear use and at least one >>> implemented use case, not for things that *might* be useful at some point. >>> We can always add it back later (post-luna) once it has become clearer what >>> the usage patterns are. >>> >>> In thinking about this I'm wondering whether we should be doing the new >>> stuff first in an incubator model based off of the main UIElements.ecore. >>> This would allow for investigations of various proposed model shapes while >>> not churning the API model, what do you think ? >>> >>> If anybody has examples and wants to make a case for keeping the >>> elements in the model come forward *now *. >>> >>> Onwards, >>> Eric >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Mail: [email protected] > Web: http://www.teufel.net > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > -- Mail: [email protected] Web: http://www.teufel.net
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
