My biggest pro is keybinding hacks are gone! Tom
Von meinem iPhone gesendet > Am 14.01.2014 um 16:37 schrieb Eric Moffatt <[email protected]>: > > Marc, thanks dude you beat me to it. The idea was indeed to bring Dialogs / > Wizards under DI (like a custom Detached Window). This will not only allow > folks to use the inherently simpler DI patterns but should also facilitate > the (re)use of Parts / Commands within the Dialog since they're DI-based... > > Doug, early on we decided that modeling all the way down to the widget level > was too deep (i.e. too much work...;-) to own and there are other mechanisms > (i.e. WindowBuilder, XWT...). I don't believe that there's anything in the > current approach that would prevent those that are interested from using the > widget editor of their choice when defining the dialog's structure. > > Eric > > > <graycol.gif>Marc Teufel ---01/14/2014 10:15:43 AM---When I implement Dialogs > these days, it is not that easy to bring it together with Dependency Inject > > <ecblank.gif> > From: > <ecblank.gif> > Marc Teufel <[email protected]> > <ecblank.gif> > To: > <ecblank.gif> > E4 Project developer mailing list <[email protected]>, > <ecblank.gif> > Date: > <ecblank.gif> > 01/14/2014 10:15 AM > <ecblank.gif> > Subject: > <ecblank.gif> > Re: [e4-dev] MDialog / MWizard will be removed in M5 > <ecblank.gif> > Sent by: > <ecblank.gif> > [email protected] > > > > 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
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
