[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] Declarative UI in E4
|
Kevin,
In wazaabi 2.0, I choose to use 2 metamodels: one is abstract and holds
the behavior which is not SWT specific. The second one is concrete and
tries (with respect to the abstract one) to be as close as possible to
SWT. This has been done for allowing other concrete models like Swing
(which is not one of the first target of E4, I know).
The runtime engine is split up into 2 parts respecting the separation of
metamodels.
The mechanism is based on controllers which manage views (1 model <->1
controller <->1 view) and the view contains usually a widget.
The view creation is not dependant of the parent, even if the underlying
SWT widget is.
It allows the reparent of any view and/or provides skinning capabilities.
This separation allows also stylesheet mechanism (not implemented yet).
(A button could be systematically embedded in a container)
IMO, having a 1:1 mapping means we just reproduce the implicit model of
the APIn then we accept as a model langages constraints.
For instance, for the checkbox button, is the selection (check) an event
or a property ?
In wazaabi it acts as a property (and of course, EMF allows us to add
Adapter on it).
My current work is focused on databinding model & engine. After this
(important step), I will try to build E4 demo using wazaabi.
Regards,
Olivier
Kevin McGuire a écrit :
My impression was that XWT and Hallvard's model were modelling at two
different levels. At least, that's the interesting part to me (and
less so, it's representation as an EMF model or XML). I admit I've
not looked closely at either due to lack of time (sigh), but at a
broad level, I believe that Yves approach maps more closely to the
widgets but is not a direct representation of them (close but not
1:1), while as Hallvard's is a more abstract approach which could
facilitate higher level UI expressions, eventually generated down to
widgets (even less 1:1).
I'm not sure I've characterized them accurately and if not apologies.
I think both approaches are interested and valid. A close mapping to
the widget structure allows for GUI builders,
serialization/deserialization, testers, etc. A more abstract model
might allow you raise the level of expression of the UI to more
functional needs ("I need a list of directories" vs. "I need a list
widget whose content provider gives me directories").
As a super-minor example, in CSS you can set margins. Our SWT widgets
don't have equivalent API for margins. The way to implement it in SWT
is with a Composite and layout. But my declarative UI likely won't
have that composite. Ideally the widget generation would be in
cohoots with CSS and gen the right composites with layout values. So
not 1:1.
Kevin
*David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>*
Sent by: e4-dev-bounces@xxxxxxxxxxx
01/27/2009 03:03 PM
Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
To
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>, andy@xxxxxxxxxx
cc
Subject
[e4-dev] Declarative UI in E4
Two things, by way of moving the discussion forward while the IP
machine grinds along:
(The impatient or overworked can read just the boldfaced text and get
the gist of what I'm saying. ;-)
*
Thing #1:)*
My understanding is that our status is that Hallvard's code is making
its way through the IP Review process and onto the E4 server.
In the meantime, I had an idea that might unify the two current proposals.
(If I mis-characterize any of this, please correct me, but here is my
understanding of our current state:)
1) Hallvard's proposal is an XML layer on top of an EMF model that is
connected to the UI.
2) Yyves's proposal is to map XAML 1:1 to the SWT API. He calls the
resulting API XWT.
Here's what I was wondering: *Yyves, would it be possible/desirable
to make XWT map 1:1 to Hallvard's EMF model rather than straight to
SWT? This seems like it might be a sensible approach to unifying both
proposals.*
If the answer is "yes", I'd very much like to play with that and see
what the resulting code looks/feels like.
*
Thing #2:)*
I've been thinking about the ways we have discussed for abstracting
and simplifying UI creation. So far, we have only focused on XML
representation, but I recalled that Andy Maleh created (and proposed)
Glimmer, a JRuby-based UI DSL project. And I've been interested in
translating Glimmer's ideas into Scala.
(I noticed that Boris invited Andy to participate over here, and
regrettably, he has not materialized yet. Since I know Andy
personally, I'll reach out to him and invite him to join the
conversation.)
In any case, *I want to make sure that whatever we do does not
preclude Glimmer-like things in alternate JVM languages, whether
JRuby, Scala, JavaScript, etc.*
*
In the abstract, it seems like it ought to be possible to map
Glimmer(.JRuby | .Scala) to EMF just like Hallvard maps XML to EMF.*
Which brings me to my
*
Conclusion:)*
*
Hallvard: Any ETA on when we will get to see your code at Eclipse.org?*
I'd really like to get my hands on both of these proposals and play
with them. :-)
Best regards,
Dave Orme
PS: Andy: I've CC'd you on this mailing list message. If you're
interested, please add yourself to the list so you can take part in
the ongoing conversation. You know you're welcome here. ;-)
_______________________________________________
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
------------------------------------------------------------------------
Internal Virus Database is out of date.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.13/1912 - Release Date: 23/01/2009 18:54