Re: [e4-dev] MDialog Implementation

[Marco Descher <marco@xxxxxxxxxx>]

Hy Eric, Wim,

@Wim: Maybe Dialogs should be seen within the context of a Handler? This way you would not be required to do the searching, and I think that it is the more natural way. So you could still define Dialogs at the root of the application, but have them connected to the Handler in the appModel.

I am missing open() too … I don’t think you are primed towards JFace, there has to be some way to work with the concept of the dialog .. and open() is certainly a valid method to it, while close() should happen through the dialog itself - no? Isn’t that just the pure (implementationless) semantics of a dialog?

What about the following example, a dialog being a „parameter“ of a handler:
== MODEL
/Application
/Application/Dialogs/
/Application/Dialogs/MySelectDialog
/Application/Handlers
/Applicaiton/Handlers/MySelectHandler/Dialog/MySelectDialog

// in Handler
@Execute
public Object execute(MDialog dialog) {
	// do stuff
	// open dialog and get return value
	// dialog has its own context injection
	Object returnValue = dialog.open();
}

// in Dialog
@Execute
public Object execute(Shell shell, MHandler handler, MCommand command) {
	// call the specific dialog implementation
	// return output to handler if appropriate or act on specific dialog
}

@Eric
>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 
I like this very much, as I try to generate documentation out of the model, I am mostly interested in seeing the connection between commands and the dialogs they employ
>(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...;-).
Thanks! I hoped about that, as I said in my mail! - I want to see dialogs and wizards in the app model. You being optimistic makes me being optimistic :)

>>our 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).
Please see the above proposal

>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...
We have an example here, where we directly use OSGI services within the dialog to select elements. Currently this happens via the handler which then passes
the osgi reference to the dialog.

Thanks guys,
marco

An 29. Jänner 2014 at 11:29:52, Wim Jongman (wim.jongman@xxxxxxxxx) schrieb:
>  
> Good points Marco and Eric.
>  
> I am missing the "open" method on the MDialog[1] and MWizard.  
> Or am I just
> primed towards JFace dialogs?
> I don't want to use the model to lookup my MDialog [2] manually  
> but have it
> injected in some way?
>  
>  
> [1]
> https://github.com/E4Examples/mdialog01/blob/master/mdialog01/src/mdialog01/parts/DialogPart.java  
> [2]
> https://github.com/E4Examples/mdialog01/blob/master/mdialog01/src/mdialog01/handlers/OpenHandler.java  
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>