My biggest pro is keybinding hacks are gone!
Tom
Von meinem iPhone gesendet
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
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 <dschaefer@xxxxxxx>
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 <teufel.marc@xxxxxxxxxxxxxx>
Reply-To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date: Tuesday, January 14, 2014 at 12:43 AM
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
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 <pawel@xxxxxxxxxxxxx>
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 <tom.schindl@xxxxxxxxxxxxxxx> wrote:
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
--
Mail: teufel.marc@xxxxxxxxx
Web: http://www.teufel.net
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
--
Mail: teufel.marc@xxxxxxxxx
Web: http://www.teufel.net _______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|