Hi Hallvard, Regarding the comparison between XAML and XSWT, I agree with you.
As for the goals, I think the goal (1) is a wrong goal for XML since there are other formats are more compact like JSON, or binary directly. The goal (2) is necessary as declarative UI language. The goal (3) is rather than a model in memory. I vote (2) + (3). yves -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallvard Trætteberg Sent: Sunday, November 09, 2008 4:54 PM To: E4 developer list Subject: Re: [eclipse-incubator-e4-dev] Declarative UI Kevin, Kevin McGuire wrote: > Shall I try to pick a time in say about two weeks? OK for me. It has been mentioned that some will meet at ESE. I'm going there myself, but haven't yet received a confirmation about the e4 symposium. I was a day late with the position paper (didn't post here but to the email address found in the call), but still I hope to be allowed to attend. > Specifically, while it would be good to have presentations on XSWT, XUL, etc. > I think the agenda has to be more around approaches and goals. In the last postings (Yves Yang and David Orme), there has been some comparison of XML notations (XAML and XSWT). As pointed out by Yang, XSWT is perhaps more targeted at serializing SWT. Or rather, it is a description of how to (procedurally) _build_ a specific SWT UI, while a XAML is a (declarative) model of the (initial) _state_ of a UI. David and Yves, do you agree? Whether or not this difference is important, depends on the goal. If the goal (1) is a compact notation from which to render an SWT UI, I think XSWT's approach (guessing the meaning of names, based on type information acquired by means of reflection) is best. If the goal (2) is a model for describing the state of the UI, a model which lends itself to generation, transformation and other processing, something XAML-like may be best. A third (level) goal (3) is having a "live" model which is kept in sync with the running UI. Such a model can provide a more uniform, API-independent way of manipulating and listening to the UI. These are different goals I can identify, and that I hope is a constructive contribution to this discussion. Personally, I favor goal (3), a model supporting live syncing with the real UI. If we design this model using EMF, we get scripting and databinding for free (it already exists). I think we can still use XSWT, XAML and other XML languages as concrete syntaxes, since they may be more usable than EMF's native one. The XSWT processor can we thought of as a compiler that generates the EMF model as intermediate code, instead of building the SWT UI directly. It should also be possible to generate Java code from the EMF model, or perhaps compile it directly to bytecode, for use in mobile applications. 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
