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
Dirk Fauth
---10/10/2013 09:38:12 AM---In terms of reusability and the
concept of e4, using MPart for wizard pages might be
sufficient. Int
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 <lars.vogel@xxxxxxxxx> 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 <emoffatt@xxxxxxxxxx>
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
Tom 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
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 <tom.schindl@xxxxxxxxxxxxxxx
> <mailto:tom.schindl@xxxxxxxxxxxxxxx>> 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 <lars.vogel@xxxxxxxxx
> <mailto:lars.vogel@xxxxxxxxx> <mailto:lars.vogel@xxxxxxxxx
> <mailto:lars.vogel@xxxxxxxxx>>>
> >
> > Having dialogs and wizards in the model
would definitely be more
> > consistent IMHO.
> >
> > Am 09.10.2013 11:50 schrieb "Tom Schindl"
> > <tom.schindl@xxxxxxxxxxxxxxx
> <mailto:tom.schindl@xxxxxxxxxxxxxxx>
> <mailto:tom.schindl@xxxxxxxxxxxxxxx
> <mailto:tom.schindl@xxxxxxxxxxxxxxx>>>:
> >
> > 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
> > e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
> <mailto:e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>>
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
> >
> >
> >
_______________________________________________
> > e4-dev mailing list
> > e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
> <mailto:e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>>
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
> >
> >
> >
> >
> > --
> > Mail: teufel.marc@xxxxxxxxx <mailto:teufel.marc@xxxxxxxxx>
> <mailto:teufel.marc@xxxxxxxxx <mailto:teufel.marc@xxxxxxxxx>>
> > Web: http://www.teufel.net
> >
> >
> >
_______________________________________________
> > e4-dev mailing list
> > e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
> >
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx <mailto: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
_______________________________________________
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
|