RE: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled'workb

["Yves YANG" <yves.yang@xxxxxxxxxxx>]

We have implemented XAML in Java: http://www.soyatec.com/eface. I should say
XAML is nothing in XML it-self. It has not a fixed schema unlike XUL, just
relies on the WPF library. The key feature is the dynamic mapping of XML
with code-behind class.
	XML	 	 Programming language
	---------------------------------
	Element   -> Class
	Attribute -> Property
	Event     -> Event
There are other concepts useful such as "attached property", "dependency
property". The "attached property" property is mainly used to handle the
layout:
	<Canvas>
          <Button Canvas.Left="10" Canvas.Top="20">
	</Canvas>

The "dependency property" provides a resolution mechanism of property
default value. It is very useful for template and style customization. 

I believe we can use the same concept for SWT directly. We are open to
contribute our knowledge of XAML on this new framework, even the source
codes (or directly the product) in Eclipse.

Best regards
Yves YANG
-----Original Message-----
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Markus
Voelter
Sent: Friday, April 04, 2008 7:04 PM
To: E4 developer list; voelter@xxxxxxx
Subject: Re: [eclipse-incubator-e4-dev] Initial discussion on the
'modelled'workbench UI

>>> if you look at what XUL or Microsoft's UI markup
>>> language do (I forget the name)
>
> I think you're referring to XAML, right?

I think so, yes (as I said, I forget the name :-))

Markus

>
>
>
>
>
> "Markus Voelter" <voelter@xxxxxxxxxxxxxx>
> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> 04/03/2008 03:09 PM
> Please respond to
> voelter@xxxxxxx; Please respond to
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>
>
> To
> "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled'
> workbench UI
>
>
>
>
>
>
>> I call this 'reinventing the flat tire' because the result isalways
>> worse that some other 'real' wheel...;-).
>
> :-)
>
>> Ed's comment "Using EMF models would be a boon because they would
>> directly enable a rapidly growing stack ofmodeling technology." is (to
>> me)
>> somewhat scary because most of our clients don't want a 'rapidly
> growing'
>> anything, they want a rapidly -shrinking- platform (thus e4). The
> general
>> fear is that EMF may already suffer from the 'bloat' and intra-package
>> dependencies that we're trying to eliminate in the platform.
>
> Of course the version of EMF that would be put to use
> in E4 would be a new, evolved version of EMF, where some
> of these (alleged) issues could be addressed if they really
> exist (I don't perceive EMF as big and bloated).
>
> Also, I think being able to reuse the "rapidly growing" modeling stack
> is actually an advantage, because it allows E4 to really just implement
> a minimal core (e.g with a simple scripting/CSS-like config language)
> while still optionally keeping the doors open for more powerful  
> approaches
> if people want to use those.
>
>> If we're anticipating having the model as a 'first class' concept then
>> we're talking about placing it much nearer to the eclipse 'core'
>> (equinox?). At this level size counts!! At minimum I'd expect that JFace
>> would depend on it so we can provide 'modelled' JFace viewers, etc.
> Right
>> now someone can simply get JFace/SWT and some GUI done...how much extra
>> footprint would be needed to support EMF?
>
> just a hint: if you look at what XUL or Microsoft's UI markup
> language do (I forget the name) than this is very similar. Done
> right (i.e. if the minimal core is isolated) then it's certainly
> feasible
>
>
> Markus
>
>
>



-- 

Markus Völter

voelter - ingenieurbüro für softwaretechnologie
Grabenstrasse 4, 73033 Goeppingen, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@xxxxxxx

Web: http://www.voelter.de
Blog: http://www.voelter.de/blog
Podcast: http://www.se-radio.net

PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev