>1. is it possible to set sample code wich load the XAML file? The
XAML loader return the root of SWT Component created or the DOM Document? After
how can we access into Java to a particulary widget (like
document.getElementById(....))? (I suppose with attribute name, but could you
give me a sample please?)
Yes, of course.
Yes. We have a class EXaml.findElementByName(Widget
context, String name); We have a scope mechanism: one file corresponds to one
scope. A name in a scope is unique.
The name is defined as following way:
<Button
x:Name=”myButton”/>
So from the root object, you can call EXaml.findElementByName(root,
“myButton”);
<Composite
xmlns="http://www.eclipse.org/swt/presentation"
xmlns:x="http://www.eclipse.org/swt">
<Button
x:Name=”myButton”/>
</Composite>
Widget widget = EXaml.load(“hello.swt”);
Button button = (Button) EXaml. findElementByName(widget,
”myButton”);
You can load it in a container:
Widget widget = EXaml.load(container, “hello.swt”);
>2. Data Binding
>
>You give this sample <Label text="{binding
path=Name}"/>
>but what about source? I suppose we can have <Label text="{binding source=p path=Name}"/>
>but how do you register the instance person with key=p?
The source is the “data context”
of Label. Each node may have a “data context”. If the data context of
a node is not set, its data context will be its parent’s.
You can set up a “Source”
using the StaticResource extension markup
<Composite xmlns:j="clr-namespace:ui"
x:DataContext="{StaticResource myData}">
<Composite.Resources>
< !— create a Person and asscociate it to a key -->
<j :Person
x :Key="myData">
</Composite.Resources>
<Label text="{binding path=Name}"/>
</Composite>
Here the data context of Label is same as
its parent: a Person.
Of course, you can set the resource direct
to Label as following:
<Composite xmlns:j="clr-namespace:ui">
<Composite.Resources>
<j :Person
x :Key="myData">
</Composite.Resources>
<Label text="{binding source=(StaticResource myData) path=Name}"/>
</Composite>
> Do you support Converter (UpdataValueStrategy of JFace
Databinding) ?
Yes, you can register a IConverter in
EXaml class. You can also specific a Converter for a specific binding.
>3. Event
>Is it possible to manage event with _javascript_ like HTML or XUL :
>
><script>
>function onClick(e) {
> alert(e);
>}
></script>
><Button text="Click Me!" SelectionEvent="js:onClick()">
I cannot see any issue to support this. Silverlight
1.0 uses this solution.
>At end I find your implementation is very interesting for SWT
developer. But I found it's complex for another developer which >don't know
SWT. I'm sorry with my Akrogen
but this plugin which use XUL give the capability to write Eclipse wizard to
generate >any code and none knowledge about SWT is required.
The architecture of this solution is “SWT
Centric”, almost same as XSWT but using XAML mapping technology.
>In IMHO I found it's more easy to use XUL box or HTML table layout
than >use layout and layoutdata.
Yes, it is. In this case, the change is important.
And the extensibility will be impacted, and you should also introduce another
set of APIs to handle the dynamic UI.
Best regards
Yves YANG
Soyatec - Eclipse OutSourcing & XAML
for java
http://www.soyatec.com
Tel: +33 1 60 13 06 67
Mobile: +33 6 20 74 39 45
Fax: +33 9 58 07 06 67
From:
e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Angelo zerr
Sent: Thursday, November 13, 2008
12:15 AM
To: E4 Project developer mailing
list
Subject: Re: [e4-dev] Declarative
UI
Hi,
2008/11/12 Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>
Actually I'd rather use XForms to describe them since
its a standard and has a first class notion of rendering to different devices
(one of which could be considered SWT Forms). I think in the e4 context
SWT Forms likely goes away anyway: if we're successful in embedding a richer
web UI in Eclipse desktop, that's how I'd express my forms.
Kevin, when you say XForms,you mean http://www.w3.org/TR/xforms/ ? I
found that the problem with XForms, it is oriented XML. So you can only bind
XML DOM model with UI and not another model like JavaBean.
@Yves
Hmmm,
this is an interesting point which I didn't previously understand.
When
we say "XAML" we're kind of just saying "XML++": we're not
saying what the model is, just how it looks as markup.
Thank a lot Yves for your link. I start understand the XAML behaviour. I have
several questions about eXAML:
1. is it possible to set sample code wich load the XAML file? The XAML loader
return the root of SWT Component created or the DOM Document? After how can we
access into Java to a particulary widget (like document.getElementById(....))?
(I suppose with attribute name, but could you give me a sample please?)
2. Data Binding
You give this sample <Label text="{binding
path=Name}"/>
but what about source? I suppose we can have <Label text="{binding source=p path=Name}"/>
but how do you register the instance person with key=p?
Do you support Converter (UpdataValueStrategy of JFace Databinding) ?
Could you use XPath _expression_ into the binding _expression_?
3. Event
Is it possible to manage event with _javascript_ like HTML or XUL :
<script>
function onClick(e) {
alert(e);
}
</script>
<Button text="Click Me!" SelectionEvent="js:onClick()">
At end I find your implementation is very interesting for SWT developer. But I
found it's complex for another developer which don't know SWT. I'm sorry with
my Akrogen but this plugin which
use XUL give the capability to write Eclipse wizard to generate any code and
none knowledge about SWT is required. In IMHO I found it's more easy to use XUL
box or HTML table layout than use layout and layoutdata.
Regards Angelo
11/12/2008 12:34 PM
|
To
|
"'E4 Project developer mailing
list'" <e4-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [e4-dev] Declarative UI
|
|
Hi Angelo,
XAML is a XML serialization language. It depends on which
model you apply. MS uses it for WPF with .Net framework, for Silverlight for
Web. Now, I'm developing a POC of XAML for SWT. Please take a look at
this page:
http://wiki.eclipse.org/E4/DeclarativeUI/XAML_Roundup
It maps directly to SWT.
So XAML can be used in both Abstract Model and
Real Model:
Regards
Yves YANG
Soyatec - Eclipse OutSourcing & XAML for java
http://www.soyatec.com
Tel: +33 1 60 13 06 67
Mobile: +33 6 20 74 39 45
Fax: +33 9 58 07 06 67
From: e4-dev-bounces@xxxxxxxxxxx
[mailto:e4-dev-bounces@xxxxxxxxxxx]
On Behalf Of Angelo zerr
Sent: Wednesday, November 12, 2008 6:26 PM
To: E4 Project developer mailing list
Subject: Re: [e4-dev] Declarative UI
Hi Kevin,
If I understand your comment, you say "Abstract Model or Real Model?"
When I say Abstract Model I mean XAML, XUL like and when I say Real Model I
mean XSWT
which use if I understood reflection to use native SWT widget.
Here my IMHO about that :
Pro Real Model (XSWT)
* It use the same XML Markup name that SWT (Text, Label...).
* When SWT API is improved, we can use the new feature (if we use reflection).
* Extensible widget seems more easy to implement I think.
Pro Abstract Model (XAML, XUL..)
* Can extends to any XML Markup. So we can use XAML, XHTML, XUL. I'm J2EE
developer
and I find it's helpfull to decribe UI with XML Markup that I know (like
XHTML, XUL...)
(Akrogen where you can describe UI with XUL please to people,
because you can write XUL UI,
test it into Firefox and use it into Akrogen which interpret the XUL to
SWT).
* Is not linked to renderer. Kevin I know that your goal is SWT but if we have
another renderer like VE, Java2d
I think it will be very cool to use the same Declarative UI and render it
into Java2d, SWT, SWT Forms...
If you want use SWT Forms, how can you take the difference between SWT
and SWT Forms widgets creation?
I think that extensibility is very important too :
* Add your own XML Markup to manage another thing that render widgets. For
instance I have done that into Akrogen
where you can add XML Markup <template> to XUL description to add
template (Freemarker, to use) to generate code
when Finish button of wizard is clicked.
* Add your own XML Markup to manage another widgets.
Regards Angelo
2008/11/12 Markus Kohler <markus.kohler@xxxxxxxxx>
Hi,
See my comments below ...
On Wed, Nov 12, 2008 at 11:49 AM, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
wrote:
Hi,
Well I envision a design for client-server with a declarative model like
this.
---------------------------------------------
Client
[1] Client-Device (Browser, ...)
[2] Client-Renderer (Widget-DOM) -----action--
[3] Client-DOM (EMF-DOM)
|
--------------------------------------------- |
Network /\
|
|| Model-To-Model (e.g. CDO, JSON,
...) |
---------------------------------------------
|
Server
|
[4] EMF-DOM
|
[5] BusinessLogic <--------------------------|
Do you have a RAP like design in mind when you talk about server side
rendering?
Yes. As far as I know other frameworks do the same. JFace for example. They
maintain an in-memory representation of the tree of UI components.
Because RAP supports the SWT API I think it needs to do it as well, except if
RAP would translate Java to _javascript_ in the same way as GWT does.
GWT is what I would call a "client side rendering framework",
because it does not have a representation of the UI component tree on the
server. In fact GWT applications are _javascript_ applications that happen to use
RCP calls to get and change data on the server.
I can see how a declarative ui description could be more easily translated into
code that runs on the client, but you still will need code to handle events,
construct and add new UI elements dynamically at runtime, validate user input
and soon ... If you don't translate Java to _javascript_ (or whatever your client
side language is), you will need to run that code on the server. Because of
that you probably also need a representation of the tree of UI components on
the server as well.
This is really not what you want for a highly interactive Web 2.0 style
application. You will end up with more roundtrips and more state on
the server, which will limit your performance.
Regards,
Markus
I don't know enough about RAP but as far as I have understood
it they have 2 representations of a widget (ServerSide,ClientSide) maybe
they could change their (under the assumption noone is directly
accessing widgets but instead is going through the DOM) design so that
they don't need the server side representation.
EMF's object representation is by the way not as bloated as an XML-DOM
and can be optimized further (Ed recently blogged about it). Naturally
if you have to restore [2] also on the server you are doubling memory
but I don't think this is needed (always under the assumption noone is
directly accessing widgets but instead is going through the DOM).
Tom
Markus Kohler schrieb:
> Hi all,
> Maybe I don't fully understand everything here, but what does it mean
> for memory usage if only the DOM API is available?
> Something like an XML DOM Tree typically has a big overhead compared to
> a dedicated statically typed UI Component Tree.
>
> As long as the the DOM is stored client side (like it's done with
> browser based applications), I don't see a big problem with this
> approach. But if e4 is going to support server side rendering, where the
> DOM would be in memory for each user, this could create scalability
> problems, because of high memory usage per user.
>
> I wonder whether saving some memory for the code does help, if using a
> DOM representation requires more memory.
>
>
> Just my 2 cents,
> Markus
>
> On Wed, Nov 12, 2008 at 9:03 AM, Tom Schindl
> <tom.schindl@xxxxxxxxxxxxxxx
<mailto:tom.schindl@xxxxxxxxxxxxxxx>>
wrote:
>
> Hi Kevin,
>
> Can you clarify this? I don't see a problem with going
through the DOM.
> I'd argue that someone is not even getting access anymore to
the REALLY
> widget when he/she is using declarative UI.
>
> You may ask why does one not have access to the widget:
> a) Did you ever see a WebDeveloper trying to access the real
> Native-Gecko-Button? SWT is just a renderer of the
widget
> like Gecko, ... is in a browser.
>
> b) The DOM you are seeing and the Widget-Hierarchy don't
necessary have
> a one-to-one mapping. E.g. let's say I want to have
fancy border
> drawing in SWT then my DOM looks like this:
>
> <composite border="black 2px"
layout="grid">
> <label text="BlaBla 1" />
> <label text="BlaBla 2" />
> </composite>
>
> whereas the widget structure is like this:
>
> Composite (FillLayout=margin=2,
backgroundColor=black)
> Composite(GridLayout)
> Label
> Label
>
> c) What do you script against? The real widget is not right
IMHO because
> of 2 and 3
>
> The above example of a border is the reason I'm not a friend
anymore of
> a low-level dialect like XSWT but favor some higher level of
Declarative
> UI. As long as I programm against the high-level DOM it
doesn't bother
> me how a feature gets implemented at the widget-level
> (widget-composition, gc-drawing, ....). Naturally the above
border could
> get implemented also by subclassing Composite +
PaintListener but I
> guess you'll get the point, right? By the way how is such a
problem
> solved when the border definition is coming from an
CSS-Stylesheet?
>
> When we talk about modeling the workbench it even gets worse
because
> e.g. a StackedPart can get rendered by a completely
different
> widget-type for example:
> - CTabFolder
> - TabFolder
> - Nebula-PShelf
> - ...
>
>
> Tom
>
> Kevin McGuire schrieb:
> >
> > Actually this approach concerns me: if I go through the
model, or go
> > directly against SWT, I get different notification.
It could easily
> > lead to bugs in application code. I would also
argue that the
> model is
> > then no longer a model of SWT, but rather, a model of
an enhanced SWT
> > which doesn't exist.
> >
> > Regards,
> > Kevin
> >
> >
> >
> >
> > *Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx
> <mailto:tom.schindl@xxxxxxxxxxxxxxx>>*
> > Sent by: e4-dev-bounces@xxxxxxxxxxx
> <mailto:e4-dev-bounces@xxxxxxxxxxx>
> >
> > 11/11/2008 04:29 AM
> > Please respond to
> > E4 Project developer mailing list <e4-dev@xxxxxxxxxxx
> <mailto:e4-dev@xxxxxxxxxxx>>
> >
> >
> >
> > To
> > e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
> > cc
> >
> > Subject
> > Re: [e4-dev] Declarative UI
> >
> >
> >
> >
> >
> >
> >
> >
> > Angelo zerr schrieb:
> >> Hi,
> >>
> >> I would like speak about UFace <http://code.google.com/p/uface/>
that
> >> I'm using into TK-UI <http://tk-ui.sourceforge.net/index.html>
and I
> >> find very helfull to manage Declarative UI.
With TK-UI you can
> describe
> >> UI with any XML Markup (XUL, XHTML,...) and render
it into any
> renderer
> >> (SWT, SWT Forms, Swing...) Today I'm using UFace
which is UI facade
> >> which provide a lot of think like Databinding
(based on JFace
> >> Databinding). I like UFace because anything can be
bounded :
> >>
> >> * UI widgets : any properties of (visible,
text... properties if UI
> >> widgets). For instance if you call setVisible, it
fire event so it's
> >> possible after to observe this property (with SWT
we cannot catch
> this
> >> visble event for instance).
> >
> > This is a very interesting point Angelo is raising
here. I think
> when we
> > describe our UI and directly interface with SWT people
HAVE TO program
> > against the DOM (whether it is EMF or anything else)
and not directly
> > against the widget because changes in the UI like
setVisible(),
> > setEnabled(), ... can't be synced back live to the
declarative model
> > simply because SWT is not informing us about these
changes with
> events.
> >
> > I don't see this as a problem though. By the way in
"Modeling the
> > Workbench" we identified only a hand full of
things where we need to
> > sync back from the Widget (e.g. Resize, Iconify, ...)
to the model. We
> > assume that *all* other operations are happening on
model and are then
> > reflected in the UI.
> >
> > Tom
> >
> > --
> > B e s t S o l u t i o n . a t
EDV
> Systemhaus GmbH
> >
>
------------------------------------------------------------------------
> > tom schindl
leiter
> softwareentwicklung/CSO
> >
>
------------------------------------------------------------------------
> > eduard-bodem-gasse 8/3 A-6020 innsbruck
phone ++43 512
> 935834
> > _______________________________________________
> > e4-dev mailing list
> > e4-dev@xxxxxxxxxxx
<mailto:e4-dev@xxxxxxxxxxx>
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
> >
> >
> >
>
------------------------------------------------------------------------
> >
> > _______________________________________________
> > e4-dev mailing list
> > e4-dev@xxxxxxxxxxx
<mailto:e4-dev@xxxxxxxxxxx>
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
> --
> B e s t S o l u t i o n . a t
EDV Systemhaus GmbH
>
------------------------------------------------------------------------
> tom schindl
leiter
softwareentwicklung/CSO
>
------------------------------------------------------------------------
> eduard-bodem-gasse 8/3 A-6020 innsbruck phone
++43 512 935834
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
<mailto: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
--
B e s t S o l u t i o n . a t
EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl
leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck phone
++43 512 935834
_______________________________________________
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
_______________________________________________
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