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
From: Marc Teufel <[email protected]>
To: E4 Project developer mailing list <[email protected]>,
Date: 01/14/2014 10:15 AM
Subject: Re: [e4-dev] MDialog / MWizard will be removed in M5
Sent by: [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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
