Dirk, there is indeed a struggle between two desires here; on one side we don't want our 'base model' to become overly complex but we do want its concepts to be understandable. Tags as well as the transient and persistent data maps provide a *very* flexible model, to the point that we could handle both 'Dialogs' and 'Wizards' without extending the model at all.
However it's not whether it's possible to do but rather whether our clients
(RCP authors...) would gain an advantage from having the new model element
types. In this case I see having MDialog and MWizard as deserving of their
own model classes because folks writing RCP apps already use these concepts
during their design phases.
I'm not as sure whether the WizardPage is needed though even given that it
needs to communicate to its container regarding it's 'completeness'. Note
that a Dialog also has to communicate with its container to enable the 'OK'
button (and show Error Messages?).
Elements in the base model should be at a very high level of abstraction.
For me this means MDialog...OK but MTitleAreaDialog, MMessageDialog...not
so much. That's not to say that if we identify some common attributes like
'error message' or 'finished' that we shouldn't formalize them in the
model, just that we don't want the whole kitchen sink there capable of
supporting every possible flavour of dialog / wizard in existence.
Determining whether something deserves formal existence in the model or not
is a fine line and I'd be ecstatic to come out of discussions like this
with some sort of guidelines to help future committers understand how to
make such choices...might be a good idea for a BOF ?
Eric
From: Dirk Fauth <[email protected]>
To: E4 Project developer mailing list <[email protected]>,
Date: 10/10/2013 09:38 AM
Subject: Re: [e4-dev] Now's the time to figure out what we need in e4
Sent by: [email protected]
In terms of reusability and the concept of e4, using MPart for wizard pages
might be sufficient. Introducing a new model MWizardPage could lead back to
Eclipse 3 if you are not careful.
But I also agree with Tom saying that there might be additional attributes.
Looking into WizardPage it is for example necessary to know if the wizard
page is complete. But that could also be accomplished by adding new
annotations.
Just my two cents ;-)
On Wed, Oct 9, 2013 at 5:22 PM, Lars Vogel <[email protected]> wrote:
> For the model itself how about both MDialog & MWizard extend MWindow
(since they show up as windows). Whether or not we also need the MWizard
to have a
> specific collection of MWizardPages or if we can just have the logic
manipulate an MPartStack using ids is open for me, there's are good
reasons for either way. The
> MApplication would be extended to have two new collections; 'dialogs'
and 'wizards'.
I would agree with Wim that MWizardPage might not be necessary. MPart
appears at the moment sufficient. I also like the idea of
re-using MPartStack for the wizard.
2013/10/9 Eric Moffatt <[email protected]>
Modeling the Dialogs and Wizards for an application is a good thing to
do. If you consider the model to represent the agnostic description of
what UI bits the app needs in order to function then it makes perfect
sense to say something along the lines of:
"My Contacts app needs the Contacts window, an Open Contact List dialog
and a Create Contact wizard"
This is a proper indication to anybody wishing to implement that
application on *any* platform they they'll need to supply the rendered
UI for those components.
Before getting into the model specifics I'd like to look at what Dialogs
and Wizards *are*...
- They show up in their own windows
- They both represent requests to gather information from the User
- They're transient; opened by the IDE -> closed by the User
So, the specifics of how they're modeled aside, how do the elements
communicate the results back to the IDE ? The pattern for creation seems
fairly straightforward; add all necessary input parameters into the
'localContext' used to render the Dialog / Wizard. It's less clear how
the IDE (app) then retrieves the result.
For the model itself how about both MDialog & MWizard extend MWindow
(since they show up as windows). Whether or not we also need the MWizard
to have a specific collection of MWizardPages or if we can just have the
logic manipulate an MPartStack using ids is open for me, there's are
good reasons for either way. The MApplication would be extended to have
two new collections; 'dialogs' and 'wizards'.
Note that there's a beneficial side-effect of modeling the Dialogs /
Wizards; this structure makes it completely natural to embed parts into
both Dialogs and Wizard(page)s. One of the initial problems I faced
during my demos for this was that I had to 'fake' the embedded part
being in the model (see EModelService#hostElement); if the MDialog were
modeled this would no longer be an issue.
Thanks folks, this is exactly the type of discussion I was hoping for,
Eric
Inactive hide details for Tom Schindl ---10/09/2013 09:15:51 AM---Not
strictly speaking but maybe we need some extra attributesTom Schindl
---10/09/2013 09:15:51 AM---Not strictly speaking but maybe we need some
extra attributes later on there so I would model it exp
From: Tom Schindl <[email protected]>
To: [email protected],
Date: 10/09/2013 09:15 AM
Subject:
Re: [e4-dev] Now's the time to figure out what we need in
e4
Sent by: [email protected]
Not strictly speaking but maybe we need some extra attributes later on
there so I would model it explicitly.
Rethink my proposal would change to:
MWizard extend MElementContainer<MWizardPage> {
}
MWizardPage extends MPart {
}
For MDialog we could also think of
MDialog {
MPart part
}
which is probably better alignment with a MWizard then.
Tom
On 09.10.13 15:03, Wim Jongman wrote:
> I think a MWizard is an excellent idea but do we need MWizardPages?
> Having wizard pages is specific to an implementation of a wizard.
>
> Cheers,
>
> Wim
>
>
> On Wed, Oct 9, 2013 at 2:50 PM, Tom Schindl <
[email protected]
> <mailto:[email protected]>> wrote:
>
> The concept is universal and has nothing to do with SWT / JFace.
>
> MDialog extends MPart {
>
> }
>
> MWizard extends MElementContainer<MWizardPage> {
>
> }
>
> MWizardPage {
>
> }
>
> MPart extends MWizardPage, .... {
>
> }
>
> Hack you could even see a wizard to be a specialication of
> MPartStackContainer!
>
> Tom
>
> On 09.10.13 14:40, Marc Teufel wrote:
> > Are you sure that this is really more consistent ? Dont forget:
> Wizards
> > for instance are a JFace-specific kind of thing and i always
> thought the
> > application model itself should be independent of SWT, JFace. Or
> do you
> > think of a more abstract way of integration and if yes how this
could
> > look like?
> >
> >
> > 2013/10/9 Lars Vogel <[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>
> >
> > Having dialogs and wizards in the model would definitely be
more
> > consistent IMHO.
> >
> > Am 09.10.2013 11:50 schrieb "Tom Schindl"
> > <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>>:
> >
> > On 07.10.13 16:50, Markus A. Kuppe wrote:
> > > On 10/07/2013 04:37 PM, Lars Vogel wrote:
> > >> I personally think the lack of Pojo programming
support for
> > the Eclipse IDE
> > >> is preventing a larger ecosystem to provide Eclipse 4
> > extensions. So your
> > >> work started for POJO views in
> > >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=356511
was
> > really great.
> > >> Having the same of handlers would help. Maybe it
could be
> > used to build a
> > >> perspective switcher which works in the IDE and the
RCP
> > applications.
> > >
> > > Hi,
> > >
> > > the same goes for PreferencePages. Ideally, the
preference
> > page extesion
> > > point ("org.eclipse.ui.preferencePages") would accept
POJOs
> > and not just
> > > instances implementing
> > org.eclipse.ui.IWorkbenchPreferencePage (similar
> > > to bug #356511).
> >
> > Before doing this I'd like us to discuss in more general
> if Dialog &
> > Wizards should not get part of the model!
> >
> > Tom
> > _______________________________________________
> > e4-dev mailing list
> > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
> >
> >
> > _______________________________________________
> > e4-dev mailing list
> > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
> >
> >
> >
> >
> > --
> > Mail: [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > Web: http://www.teufel.net
> >
> >
> > _______________________________________________
> > e4-dev mailing list
> > [email protected] <mailto:[email protected]>
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
> >
>
> _______________________________________________
> e4-dev mailing list
> [email protected] <mailto:[email protected]>
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
>
>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
