Home » Archived » Sapphire » Creation Review
| | |
| Re: Creation Review [message #633315 is a reply to message #633270] |
Sat, 16 October 2010 09:06   |
 Yves YANG
Messages: 688
Registered: July 2009 |
Senior Member |
|
|
| Konstantin Komissarchik wrote on Fri, 15 October 2010 19:11 | Hi Yves,
Of course, I remember the discussion, but we never iterated to concrete edits to be made to the proposal. Since you were the one driving the need for clarification, I was looking to you to clarify what exactly you wanted to see clarified. That thread sort of died out, though.
If there is still something you'd like clarified in the proposal, please respond with specifics.
- Konstantin
|
Konstantin,
For me the thread is just over. Here is the list of our last emails through PMC below.
I think the proposal should be updated by integrating the position of each project to order to make it clear for everyone.
Best regards
Yves YANG
------------------------------------------------------------ -----------------
July 10 from Yves
============================================================ ======
And there is another project PMF to deal with UI in a modeling and total abstraction way. It targets to support all kinds of data sources and UI technologies.
Best regards
Yves YANG
July 10 from Konstantin
============================================================ ======
Now unlike XWT, PMF is tackling the same problem as Sapphire, but as you will see once you've read the link that I sent earlier, the approaches are quite different.
We can discuss Sapphire/PMF comparison further if you wish, but I would much rather do that on the forum as I stated in the previous e-mail. The Tech PMC can read the forum just as well as this mailing list, but e-mails sent to this list aren't as easily accessible to everyone else interested in this technology.
Thanks,
- Konstantin
July 16 from Konstantin
============================================================ ======
Hi Yves,
Thanks for taking time to learn more about Sapphire.
I have to disagree with your assessment that e4/XWT and Sapphire are similar. The only similarity that they share is that they both use a declarative language to specify the UI, but what's actually specified is very different. There is a paragraph on this in the Sapphire project proposal, but here is another stab at an explanation... XWT specifies widgets and their detailed configurations, including layouts, etc. It is basically a declarative version of SWT. Nothing wrong with that. In fact it's a necessary evolution of SWT, but that's not what Sapphire is about. In Sapphire, the UI definition is composed of an arrangement of property editors. The developer does not specify which widgets to create nor how to arrange them in detail (no layouts). That function is left to the renderer.
In fact, it is entirely possible to have an e4/XWT definition produced by a Sapphire renderer and I fully expect that to happen at some point as Eclipse 4.x gains greater mindshare. Other integration vectors are possible too. For instance, right now, one way that Sapphire integrates with SWT is via SapphireControl, which is an SWT composite that takes a data model and a UI definition and renders everything. I can easily see an equivalent thing to plug Sapphire into an XWT definition of the e4 workbench. Note that it is not a goal of Sapphire to be a generic UI framework. I don't see ever being able to use it to describe the entire workbench. That is both unnecessary (there are better tools for that - like XWT) and would hurt Sapphire ease of use that is fundamental for its value proposition. Sapphire's strength is forms. You have less flexibility than XWT/SWT/whatever, but you develop far more rapidly with arguably better results. The developers would choose control or quicker results as the needs of the problem dictate.
Regarding PMF, I have to admit that I am confused now. From the project description and screen casts they looked similar at the fundamental level.
In both, the data model is a key input and you compose UI out properties rather than widgets. Something else decides what widgets to create. The major differences that I see is the reliance on generated code and the use of EMF for the data model. I'd live to learn more about PMF, especially the way in which it is a "more generic solution" than Sapphire. It's hard to tell right now whether collaboration is possible, but you can never tell.
Thanks for the offer.
- Konstantin
July 16 from Yves
============================================================ ======
Hi Konstantin,
I appreciate this open discussion.
>
> I have to disagree with your assessment that e4/XWT and Sapphire are
> similar. The only similarity that they share is that they both use a
> declarative language to specify the UI, but what's actually specified is
> very different. There is a paragraph on this in the Sapphire project
> proposal, but here is another stab at an explanation... XWT specifies
> widgets and their detailed configurations, including layouts, etc. It is
> basically a declarative version of SWT. Nothing wrong with that. In fact
> it's a necessary evolution of SWT, but that's not what Sapphire is about.
> In
> Sapphire, the UI definition is composed of an arrangement of property
> editors. The developer does not specify which widgets to create nor how to
> arrange them in detail (no layouts). That function is left to the
> renderer.
>From this point of design position, it does look like as PMF to deal with
high level abstraction. If we look at the current implementation of XWT,
it is true it handles the low level UI definition. But it is just a start
point. XWT is a high extensible architecture. In fact, it defines an
reusable UI infrastructure. We can easily add a new high level abstraction
on top of XWT such as property editor, Wizard page, Preference Page etc.
We have already a first experience of using XWT to define the "Properties
View" of e4 workbench by hand coding. We are working on using PMF to
generate them.
I said Sapphire is close to XWT because it is a runtime solution. PMF is
not. PMF is a MODELING Framework or precisely a toolkit to generate the
runtime. Its-self is not runtime. In one word, PMF is a UI software
engineering based on MDA. One application designed in PMF can be run in
different UI technology natively. It is not via Renderer to switch the
execution environment. For example, one application designed in PMF can be
generated to e4 using eclipse runtime, it should be generated in AJax on
Web.
I hope I make my-self clear.
Best regards
Yves YANG
July 16 from Konstantin
============================================================ ======
> If we look at the current implementation of XWT,
> it is true it handles the low level UI definition. But it is just a start
> point. XWT is a high extensible architecture. In fact, it defines an
> reusable UI infrastructure. We can easily add a new high level abstraction
> on top of XWT such as property editor, Wizard page, Preference Page etc.
> We have already a first experience of using XWT to define the "Properties
> View" of e4 workbench by hand coding. We are working on using PMF to
> generate them.
Good to know. It sounds like it would be a good idea to explore Sapphire and
XWT integration sooner than I anticipated. To be clear, I don't see Sapphire
folding into XWT for two fundamental reasons:
1. Sapphire is intended to be independent of a particular UI technology.
2. All of my current users are going to be on Eclipse 3.x for foreseeable
future.
Sapphire's UI definition is a model. It isn't bound to any one particular
syntax. There has been some discussion on the forum about using Xtext to
build a more readable language, for instance. There is no reason that there
couldn't be a syntax that's directly embeddable in an XWT definition if XWT
is as flexible as you say.
> I said Sapphire is close to XWT because it is a runtime solution. PMF is
> not. PMF is a MODELING Framework or precisely a toolkit to generate the
> runtime. Its-self is not runtime. In one word, PMF is a UI software
> engineering based on MDA. One application designed in PMF can be run in
> different UI technology natively. It is not via Renderer to switch the
> execution environment. For example, one application designed in PMF can be
> generated to e4 using eclipse runtime, it should be generated in AJax on
> Web.
Ok. I understand now.
PMF: Data Model + UI Model -> Code Generator -> Run
Sapphire: Data Model + UI Model -> Run -> Sapphire Runtime + Renderer
It sounds like the goals of Sapphire and PMF are similar, but the approaches
are quite different.
- Konstantin
|
|
|
| Re: Creation Review [message #633684 is a reply to message #633315] |
Mon, 18 October 2010 21:11 |
Konstantin Komissarchik
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
How about these specific changes? Note that I will not update the proposal until you confirm that this is what you are looking for.
1. Change section header "Relation to e4" to read "Relation to e4/XWT".
2. Add "Relation to PMF" section with following content:
"Sapphire is a framework for design time and runtime. The UI is rendered from the definition at runtime. PMF is a framework for design time. The UI is compiled from the definition at design time. PMF has no runtime aspect.
Both approaches have their advantages and disadvantages. Sapphire produces less code to distribute (no generated UI code to ship) and client code can take advantage of presentation improvements without being re-compiled. On the other hand, PMF can be used for generating UI for non-Java runtime environments."
- Konstantin
[Updated on: Mon, 18 October 2010 21:11] Report message to a moderator |
|
|
Goto Forum:
Current Time: Fri Apr 26 21:19:58 GMT 2024
Powered by FUDForum. Page generated in 0.04249 seconds |
] 
Search
Help
Register
Login
Home
