I am indifferent to having an MDialog element, that's not where my concern lies. I think all of your points on why having an MDialog element are very valid and in addition to those, from a renderer standpoint having a concrete model element for Dialogs would make it cleaner. I also agree that we should avoid over use of tags.
My issue is with the MWizardDialog. As I said, I am probably more for
having a modeled wizard than not. But it should be modeled as just a
wizard, capable of being displayed in either an MDialog or MPartStack. The
ability to use DI seamlessly in these top level elements is vital, but I
know we can do this in a generic way.
What I am thinking of is something like this:
public interface MWizard extends MPart, MUIInteractionPageContainer {
// Wizard Specific API
}
public interface MUIInteractionPage extends MUIElement, MContribution,
MUILabel, ?MHandlerContainer?, MDirtyable, ?MBindings?, MWindowElement
{
// API Common to WizardPages and PreferencePages
// like ?isComplete? / ?performFinish? / etc?...
}
Then a wizard page implementation could look like:
public class MyCustomWizardPage {
@Inject
private MWizard wizard;
...
}
I believe this story is much more powerful than going down the road of
MWizardDialog (and by no means is this story "complete").
I know I don't contribute as often as others would like, or even as much as
I would like. But that is more a function of my employer. I will try to
work something up for this in the next couple of days.
JD
On Thu, Nov 21, 2013 at 3:16 AM, Lars Vogel <[email protected]> wrote:
> > For background there *are* identifiable advantages to incorporating
> Dialogs...into the model. Mostly this revolves around allowing the dialog
> to hook into the MApplication's context chain (allowing DI > & service
> access...) as well as normalizing the hosting of MParts in the dialog.
>
> I can confirm that, in our Eclipse 4 training sessions I felt that using
> Dialogs and Wizards was a step back because DI could not be used directly.
>
> Best regards, Lars
>
>
>
> 2013/11/20 Eric Moffatt <[email protected]>
>
>> JD, this is the reason that we're starting with only the barest of
>> enhancements; we're waiting to see concrete uses before deciding whether or
>> not any other extensions are needed (or indeed if even the new ones are).
>> We realize that we could likely accomplish everything using tags but think
>> that having the model elements available will make it easier for clients to
>> more accurately define their application (and for others to more easily
>> understand what's in the app).
>>
>> For background there *are* identifiable advantages to incorporating
>> Dialogs...into the model. Mostly this revolves around allowing the dialog
>> to hook into the MApplication's context chain (allowing DI & service
>> access...) as well as normalizing the hosting of MParts in the dialog.
>>
>> Eric
>>
>>
>> [image: Inactive hide details for Joseph D Carroll Jr ---11/18/2013
>> 06:00:02 PM---I realize these changes are already in master, but I]Joseph
>> D Carroll Jr ---11/18/2013 06:00:02 PM---I realize these changes are
>> already in master, but I think we are getting too specific with our mode
>>
>>
>>
>> From:
>>
>>
>> Joseph D Carroll Jr <[email protected]>
>>
>> To:
>>
>>
>> E4 Project developer mailing list <[email protected]>,
>>
>> Date:
>>
>>
>> 11/18/2013 06:00 PM
>>
>> Subject:
>>
>>
>> Re: [e4-dev] Model changes for 4.4 M4
>>
>> Sent by:
>>
>>
>> [email protected]
>> ------------------------------
>>
>>
>>
>> I realize these changes are already in master, but I think we are getting
>> too specific with our model. Having an MWizardDialog only opens the door
>> to having an MWizardPart and IMHO that defeats the entire purpose of having
>> a generic model in the first place.
>>
>> If we are going to model the Wizard (which I can make arguments either
>> way) it should inherit from MPart if anything. I guess I am more for
>> modeling Wizards AND WizardPages because I feel that makes a better
>> argument for reuse. But all of this is for naught if we are going to
>> delineate our model so rigidly.
>>
>> I would even be for creating a model element that blurs the line between
>> WizardPage and PreferencePage (call it an MInteractionPage). Because, from
>> an abstract sense, WizardPage and PreferencePage accomplish the same thing;
>> taking some form of user interaction. Combine that with the existing DI
>> framework and there is no need to have separate entities.
>>
>> So I would vote:
>> -1 on MWizardDialog
>> 0 on MDialog
>> I think we can enhance our existing tags on MWindow to accomplish
>> everything the Dialog does (like even having a "dialog" tag).
>>
>> JD
>>
>>
>> On Tue, Nov 12, 2013 at 1:44 PM, Paul Elder
>> <*[email protected]*<[email protected]>>
>> wrote:
>>
>> Brian de Alwis <*[email protected]* <[email protected]>>
>> wrote on 11/11/2013 12:17:29 PM:
>>
>>
>> >
>> > I’d have thought we wanted MDialog to be distinct from MWindow? And
>> > aren’t wizards really a form of dialog?
>>
>> >
>> > The Workbench code (currently) assumes that it can take over and
>> > manage any MWindow. I don’t think we want the workbench to manage
>> dialogs :-)
>> >
>>
>> For the first cut, I'm going to create MDialog (subclassing MWindow),
>> and MWizardDialog subclassing MDialog. If subclassing MWindow proves to be
>> a problem, we can change it, but logically (at least on the windowing
>> systems I know of), a dialog is a window.
>>
>> Paul
>> _______________________________________________
>> e4-dev mailing list
>> *[email protected]* <[email protected]>
>> *https://dev.eclipse.org/mailman/listinfo/e4-dev*<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
>>
>>
>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
<<ecblank.gif>>
<<graycol.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
