[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] 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,
Scott
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
