atom feed23 messages in org.eclipse.riena-devAW: [riena-dev] Ridgets
FromSent OnAttachments
Scott LewisJun 17, 2008 8:09 am 
Drossel, CarstenJun 17, 2008 8:50 am 
Scott LewisJun 17, 2008 9:00 am 
Christian CampoJun 17, 2008 10:41 am 
Scott LewisJun 17, 2008 11:34 am 
Christian CampoJun 17, 2008 12:18 pm 
Scott LewisJun 17, 2008 12:34 pm 
Christian CampoJun 17, 2008 1:17 pm 
Scott LewisJun 17, 2008 1:36 pm 
Christian CampoJun 17, 2008 2:09 pm 
Volanakis, EliasJun 17, 2008 2:50 pm 
Scott LewisJun 17, 2008 3:08 pm 
Volanakis, EliasJun 17, 2008 3:19 pm 
Scott LewisJun 17, 2008 3:29 pm 
Volanakis, EliasJun 17, 2008 3:48 pm 
Alexander ZieglerJun 18, 2008 1:47 am 
Scott LewisJun 18, 2008 3:05 pm 
Drossel, CarstenJun 18, 2008 11:41 pm 
Christian CampoJun 19, 2008 12:15 am 
Alexander ZieglerJun 19, 2008 1:56 am 
Christian CampoJun 19, 2008 2:54 am 
Alexander ZieglerJun 19, 2008 3:59 am 
Scott LewisJun 19, 2008 7:45 am 
Subject:AW: [riena-dev] Ridgets
From:Drossel, Carsten (Cars@compeople.de)
Date:Jun 17, 2008 8:50:37 am
List:org.eclipse.riena-dev

Hi Scott,

sorry to disappoint you but "Ridget" just stands for "Riena Widget". There is
nothing remote about them, they only exist on the client.

A Ridget wraps an actual UI-widget but offers a higher level of abstraction and
it is independent of the UI-toolkit (SWT). The concept is to separate the UI
(View) from the logic behind in, which is moved to a ViewController. The
ViewController interacts with the actual UI-widgets through the Ridgets. It
should be possible to reuse a ViewController with a View that is based on
another UI-toolkit e.g. Swing.

A Ridget offers the most commonly used functionality (like setText(String) of a
text field) along with some extra convenience functionality. An example for the
later are the markers. A textfield can be marked as error by adding an
ErrorMarker. The marking itself (changing color, setting icons, etc.) is handled
by the Riena framework. Another example is the 'bindToModel' method for a simple
databinding with a JavaBean.

The overall intention is to reduce the complexity for the application developer
and to ensure a common look&feel across the application. If the functionality
offered by the Ridgets interface is not sufficient the developer can always
access the actual UI-widget. Then of course he loses the independence from the
UI-toolkit. The set of Ridgets is constantly getting bigger. If necessary it
should be possible for application to add its own Ridgets.

Hope that clarified things a bit. Maybe we can copy this to the wiki...

Greetings, Carsten

-----Ursprüngliche Nachricht----- Von: rien@eclipse.org [mailto:rien@eclipse.org] Im
Auftrag von Scott Lewis Gesendet: Dienstag, 17. Juni 2008 17:10 An: Riena Developers list Betreff: [riena-dev] Ridgets

Hi Rieners,

I've seen some traffic lately (and seen in the source), an indication that Riena is working on what you seem to call 'Ridgets'. I assume Ridget means/refers to 'Remote Widgets'. Is that correct?

I notice that the 'Ridgets' seem to have a method 'bindToModel' (and others of course), that seem to indicate that the (local) UI widget is being bound to (presumably) a remote model. Please let me know if this is not a correct interpretation.

I have some questions about this architecture:

1) Does it make sense to define a new/additional hierarchy of Ridget interfaces (e.g. IMenuButton, etc)? Won't this require use of yet another set of UI interfaces/classes (i.e. yours) and make it difficult/impossible for existing applications to work in a distributed fashion?

2) Given the potential for highly variable (and unreliable) performance of the network, isn't it questionable having the boundary between processes defined at the UI level (Ridget)? That is, doesn't architecture A below imply a large amount of network traffic relative to B?

Architecture A

Process 1 Process 2 Ridget (UI) -> Proxy ---> Model -> (optional UI)

compared to a replicated model approach, where a replica of the model exists on both processes? i.e.

Architecture B

Process 1 Process 2 Ridget (UI) -> Model' ---> Model -> (optional UI)

Consider, for example, X Windows (which essentially uses architecture A). It's not really a viable approach for anything but very high performance/high reliability networks (e.g. LANs). Doesn't the Ridget approach suffer from the same characteristics relative to replicated models? Further, isn't the SWT listener listener structure (i.e. the large number of view listeners...IMouseListener, etc., etc) problematic? That is, for mouse moves (e.g.), in many cases won't this result in (frequent) synchronous remote calls to update the remote Model...and generate a large amount of traffic?

Thanks,