Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Model changes for 4.4 M4
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 <lars.vogel@xxxxxxxxx> 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 <emoffatt@xxxxxxxxxx>

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


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 <jdsalingerjr@xxxxxxxxx>

    To:

E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,

    Date:

11/18/2013 06:00 PM

    Subject:

Re: [e4-dev] Model changes for 4.4 M4

    Sent by:

e4-dev-bounces@xxxxxxxxxxx



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 <pelder@xxxxxxxxxx> wrote:
    Brian de Alwis <briandealwis@xxxxxxxxx> 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
    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



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


GIF image

GIF image

Back to the top