Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] MDialog / MWizard will be removed in M5

> @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 <dschaefer@xxxxxxx> 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 <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:
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 <emoffatt@xxxxxxxxxx>:

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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev



_______________________________________________
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



Back to the top