[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pmf-dev] [Wazaabi] Introduce dataObject attribute
Hi Hallvard,

At the moment there is two distinct possibilities for tracking changes. For UI (and often platform specific) events, there is an EventHandler mechanism which listens 'omuseMove', 'selection' etc... (I added a artificial one : 'refresh' sent the first time the UI is displayed). When triggered the event handler executes the method of the class attached to it using an URI.
The URI approach allows osgi, non osgi mechanism and is easily extendable to other langage calls (urn:js:xxx).
The second way to react to changes is included in the binding mechanism (and could be moved elsewhere if needed).
We can attach it to any EMF object feature (reference and/or attribute). I did it test yet with 'every feature' but it should work.

In the list of potential changes you provide :

- the key of a ContextContent can change
--> I don't see any application of this case, since the designer himself usually decides to which key he attachs a value, but it is doable since ContextContent is an EMF Object
- the value of a ContextContent can change
-->ContextContent is itself a EObject therefor adaptable
- a set of ContextContent-objects in a Context can change
-->'content' is a feature, therefor adaptable
- these changes can happen at any point above a widget
-->I am sorry, I do not understand this last one :-(, could you, please, provide an exemple ?

The Context is a map, but I don't think the EMF maps could be listened like EMF objects (changes of value for instance....)


In TM, the ResourceSet containing the TM model could also contain a data resource. The top-level object of this resource was automatically set as the dataObject of the top-level TM container. This would then trigger a script attached to this object, that would set the dataObject of contained widgets (containers and controls).

=>In wazaabi, the first time you display the UI, the 'refresh' event is sent to every widget (including of course, the top level one). Every bound widget holds zero or many binding(s) (source, target, updateStragegy). The refresh event could be a trigger of a binding. For instance, source= '$library/@name', target= '@text' . The Xpath like is always resolved on the widget context,so '@text' should be an attribute of the widget (if not, I did not decided yet whether it souhld throw an error or not (or a paramtrized combination of both)).


---------------
This would propagate down to the leaf nodes of the hiearchy. Of course, there would also be scripts that set visible features like text and icon, selected element etc. based on the dataObject. Fairly simple, put powerful. I think this indicates a difference between TM and Wazaabi: TM utilizes scripting for many purposes (event-handling, databinding, ...), while Wazaabi provide more special-purpose and declarative mechanisms.
---------------

The purpose is to reduce as much as possible the non-declarative approach while allowing scripting/programation  to those who want to use it (or when the case is too complex to be managed by scripting).

Olivier



2010/4/28 Hallvard Trætteberg <hal@xxxxxxxxxxx>
On 28.04.10 12.29, Olivier Moïses wrote:

A such mechanism exists already in wazaabi. In the core metamodel, the
runtime package owns Context which is an interface implemented by Widget.
The Context has a content which a transient collection on
ContextContent. The ContextContet is a key/value pair.

I noticed the Context class, but didn't realize it had this purpose. I can see that this is a useful design. The drawback is that it's difficult to listen to (all) changes that affect a specific widget, since such a change can happen in many places:
- the key of a ContextContent can change
- the value of a ContextContent can change
- a set of ContextContent-objects in a Context can change
- these changes can happen at any point above a widget

Perhaps you have implemented a kind of adapter that helps you listen to the Context and ContextContent objects?

BTW, the Context looks and feels like a Map. I think EMF has a way of actually generating a map implementation, see http://wiki.eclipse.org/EMF/FAQ#How_do_I_create_a_Map_in_EMF.3F


The missing point, at the moment, is a mechanism (based on annotation)
which 'fills' the context at runtime when the UI is (first) displayed.

In TM, the ResourceSet containing the TM model could also contain a data resource. The top-level object of this resource was automatically set as the dataObject of the top-level TM container. This would then trigger a script attached to this object, that would set the dataObject of contained widgets (containers and controls). This would propagate down to the leaf nodes of the hiearchy. Of course, there would also be scripts that set visible features like text and icon, selected element etc. based on the dataObject. Fairly simple, put powerful. I think this indicates a difference between TM and Wazaabi: TM utilizes scripting for many purposes (event-handling, databinding, ...), while Wazaabi provide more special-purpose and declarative mechanisms.


Hallvard
_______________________________________________
pmf-dev mailing list
pmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pmf-dev