> @Inject MyService service > > to get the Service the standard way...
and @Inject MyDialog dialog dialog.open(); Cheers, Wim On Tue, Jan 14, 2014 at 4:03 PM, Doug Schaefer <[email protected]> wrote: > Cool. That's a great example. So it's really about DI, not the renderers. > > Sent from my BlackBerry 10 smartphone on the Rogers network. > *From: *Marc Teufel > *Sent: *Tuesday, January 14, 2014 10:01 AM > *To: *E4 Project developer mailing list > *Reply To: *E4 Project developer mailing list > *Subject: *Re: [e4-dev] MDialog / MWizard will be removed in M5 > > 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 > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
