[
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
>