Re: [e4-dev] MDialog Implementation

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

Marco, Thank you, it's this type of discussion that we need to have to arrive at the correct compromise...

I think you're correct; simpler Dialogs do not need  to be managed through the rendering code but we should allow this for clients that prefer symmetry over simplicity (i.e. having *all* dialogs modeled for doc purposes...). The advantages come whenever you want the dialog to contain other modeled elements (Parts, Commands/Handlers...). With its current simplicity in the model maybe it's best if we look at MDialog as allowing a 'connection' to the IEclipseContext structure rather than thinking of it as a 'deep' model of the dialog's mechanics.

As far as the advantages go I think that you're being somewhat pessimistic; there are any number of cases where embedding  a part into a dialog makes perfect sense. One example is for us to replace the stupid ErrorDialog with one that embeds the Error Log view rather than just telling the user to open it themselves...;-).

Your comments about not having a nice pattern to manage things or to customize the dialog Messages etc are quite valid. We'll likely want to refine this model in future releases once we have a better handle on what we *really* need (which is the reason for needing 'experience' with the API and why we need this type of conversation).

Nobody's yet demonstrated how being linked into the IEclipseContext structure is helping them populate the dialog or its contents yet (nor how to use the context to store / retrieve results from the dialog). That's something I'd really like to see a demo of...

Eric


Marco Descher ---01/28/2014 10:20:08 AM---Hy there, we took a closer look at the Dialog implementation, trying to realize a SelectionDialog an

From:	Marco Descher <marco@xxxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Cc:	Thomas Huster <huster@xxxxxxxxxx>
Date:	01/28/2014 10:20 AM
Subject:	Re: [e4-dev] MDialog Implementation
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

Hy there,

we took a closer look at the Dialog implementation, trying to realize a SelectionDialog and an EditDialog.
For both of these we do NOT see a real advantage in using the Dialogs out of the application model. Please
get your own impression - all statements biased! I am really sorry about this insight, I hope somebody finds
an argument FOR dialogs and wizards.

=== CONS
FIRST off, it does not really make sense to re-use a part within a dialog, as the usage is different. Consider
a selection, in a part you do not confirm this selection, it happens on the selection itself propagating to the
ESelectionService .. now use this in a dialog and tell the system to wait for [OK] to be pressed … you would
have to remove the selectionChangedListener.

Re-Usage does only make sense with shared Composites … e.g. AbstractDetailComposite both used in part and dialog.

===
SECOND there is no current way to customize the dialog enough. 
		 E.g. do I need OK, CANCEL, YES, NO, WHATEVER …?
		 How do i set the TitleMessage, or the ErrorMessage if I want to use it?
The further i abstract the dialog - the more I converge against a simple handler class calling a dialog. - We ended up
with a SelectionDialog with content

@Execute /** called on dialog.open() **/
public Object open(Shell shell) {
		 // doWhatever
		 // return something
}

that would have been called in a handler like

@Execute /** HANDLER **/
public void execute(MDialog(„id.of.dialog“) dialog) {
		 Object retVal = dialog.open();
		 // say what
}

SO IMHO, a Dialog is just a „specialized“ handler. So the question arised if we could add something to the handler to ease Dialog
usage?! - Not really … everything is already there, readily delivered via DI.

=== PROS ====
ONE A good thing would be to have a central dialog pool, where you can fetch dialogs by a simple string. This would allow fragments
to provide or override dialogs, but the MDIalog would have to be extended with .close() and .getReturnValue() to support this.

==== END



An 21. Jänner 2014 at 18:53:30, Wim Jongman (wim.jongman@xxxxxxxxx) schrieb:
>  
> The MDialog behaves now exactly like an MWindow with the same  
> renderer and
> model structure. In this sense its programming is awkward/unexpected  
> because instead of having a direct class to implement we implement  
> children
> controls (e.g. one or more MPart).
>  
> In the feeling of the programmer, the Dialog is mostly "smaller"  
> than a
> Part. It most of the times contains limited content (a warning,  
> a
> confirmation, a list to select from). As it stands now, the implementation  
> of MDialog is "more work" than that of MPart.
>  
> Also the activation of the MDialog (the way I programmed it) feels  
> a little
> uneasy as you can see from my implementation [1]
>  
>  
> [1]
> https://github.com/E4Examples/mdialog01/blob/master/mdialog01/src/mdialog01/handlers/OpenHandler.java  
>  
>  
> On Tue, Jan 21, 2014 at 4:09 PM, Eric Moffatt  
> wrote:
>  
> > Beauty, this is the type of conversation we need...
> >
> > My recommendation would be to first start by getting the simplest  
> of cases
> > working (i.e. just bring up a dialog and don't worry whether  
> or not the
> > buttons are defined in the model...). This should get us some  
> idea of how
> > the dialog interacts with the contexts which is where this is  
> truly
> > unexplored territory. Once that pattern becomes settled we'll  
> be in a
> > better position to evaluate what else needs to be done model-wise.  
> >
> > Eric
> >
> >
> > [image: Inactive hide details for Wim Jongman ---01/21/2014  
> 03:03:34
> > AM---(move to a separate thread) I have made a first attempt  
> to im]Wim
> > Jongman ---01/21/2014 03:03:34 AM---(move to a separate thread)  
> I have made
> > a first attempt to implement MDialog [1]. It is hooked to th
> >
> >
> >
> > From:
> >
> >
> > Wim Jongman  
> >
> > To:
> >
> >
> > E4 Project developer mailing list ,  
> >
> > Date:
> >
> >
> > 01/21/2014 03:03 AM
> >
> > Subject:
> >
> >
> > [e4-dev] MDialog Implementation
> >
> > Sent by:
> >
> >
> > e4-dev-bounces@xxxxxxxxxxx
> > ------------------------------
> >
> >
> >
> > (move to a separate thread)
> >
> > I have made a first attempt to implement MDialog [1]. It is hooked  
> to the
> > "Open" command.
> >
> > I Defined a MDialog with visible=false, toberendered=false  
> and a Part as
> > control (called DialogPart).
> > The part implements the JFace Dialog class and I have made a small  
> impl in
> > the createDialogArea
> > The @postconstruct is hooked to the open() method
> >
> > Then in the openhandler I lookup the MDialog from the model and  
> flip
> > toberendered "on" to open the dialog and then "off" after the  
> dialog
> > returns.
> >
> > Please clone the repo and take a look to get some inspiration  
> on how this
> > can be improved
> >
> > [1] *https://github.com/E4Examples/mdialog01*  
> >
> >
> > Cheers,
> >
> > Wim_______________________________________________  
> > 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