Hi Hallvard,
> This is the target of a lot of research within my community (model-based
UI
> design), including my own Diamodl.
Cool, I'd like to learn more.
> You haven't touched upon the concept of live model. Should it be based
on XML's
> DOM? What is the benefit of using (a modeling framework like) EMF?
Yes good point. I think a live model can be valuable if your goal is
using the in-memory model as a kind of unifying structure to do higher
level transforms against (e.g. mapping high level model B to literal model
A). It's also great for live GUI builders. It can simplify access, which
is what we're seeing for the workbench model work ("Yahoo, its now so easy
to turn off the close box for a view!") although I'm not sure if here the
benefit is by way of correcting existing architectures by bringing
separate pieces together under one conceptual model. For "normal"
programming and case (A) of a literal SWT model though, I'm likely to just
write against the SWT Java APIs rather than a model of the SWT structure.
OK maybe in some specific cases I need to create the stucture without
attaching it to its parent yet, which SWT requires.
My current feeling is that if I were starting from scratch, EMF seems the
right approach since I get lots for free in a well thought out and
hardened framework. Specifically, I get both serialization and a
consistent in-memory model. I don't really care about what the stuff
looks like on disk (nor should anyone). But kind of in response to
Angelo's initial question, I wouldn't immediately discount an XML markup
and DOM based parser, since it may suite my needs perfectly.
I guess it all depends on what our goals are and why.
Regards,
Kevin
Hallvard Trætteberg <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/10/2008 05:24 PM
Please respond to
E4 developer list <[email protected]>
To
E4 developer list <[email protected]>
cc
Subject
Re: [eclipse-incubator-e4-dev] Declarative UI
Kevin,
Kevin McGuire wrote:
>
> Hallvard, good summary.
Thanks!
> A) A "literal" model of the UI.
This is the target of most XML formats. Although XSWT and XAML are
different in
some respects, I believe they both target this. The difference is to what
extent
they describe a process of building the UI or the state of the final UI.
The
latter will more easily support a live model, since changes to the DOM
will be
easier to map to "equivalent" changes to the UI.
> B) An abstract model of UIs (say, functional).
This is the target of a lot of research within my community (model-based
UI
design), including my own Diamodl. As you say, this does not replace A),
but
builds upon it.
> These two aren't mutually exclusive. If you're doing (B), its probably
> handy having (A) so you can do a model to model transformation as the
> path to instantiating the actual widgets.
Yes, this is exactly why I'm using XSWT in my model-based runtime.
You haven't touched upon the concept of live model. Should it be based on
XML's
DOM? What is the benefit of using (a modeling framework like) EMF?
Hallvard
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
