Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] MDialog Implementation

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
>  



Back to the top