[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Declarative UI
|
Hi Yves,
This indeed looks nice. Can you by chance show me the XAML for
TabFolder/CTabFolder there you need to deal with references to composite
because you pass them to CTabItem#setControl(), right?
Tom
Yves YANG schrieb:
> 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 <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
> <mailto:markus.kohler@xxxxxxxxx>>
>
> Hi,
>
> See my comments below ...
>
>
>
> On Wed, Nov 12, 2008 at 11:49 AM, Tom Schindl
> <tom.schindl@xxxxxxxxxxxxxxx <mailto: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>
> <mailto: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>
>
> > <mailto:tom.schindl@xxxxxxxxxxxxxxx
> <mailto:tom.schindl@xxxxxxxxxxxxxxx>>>*
>
> > > Sent by: e4-dev-bounces@xxxxxxxxxxx
> <mailto:e4-dev-bounces@xxxxxxxxxxx>
>
> > <mailto: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>
>
> > <mailto:e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>>>
> > >
> > >
> > >
> > > To
> > > e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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 <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
