Re: [e4-dev] Declarative UI

["Markus Kohler" <markus.kohler@xxxxxxxxx>]

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> 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>*
> Sent by: e4-dev-bounces@xxxxxxxxxxx
>
> 11/11/2008 04:29 AM
> Please respond to
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
>
>
>
> To
>       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
> 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