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


Comments below.


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

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

So, a general listening approach should handle this case, or model the key as unmodifyable.

- 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

Since fetchValue looks up in the hierarchy, a widget at one level may be affected by changes to a widget above (its ContextContent objects).

'fetchValue' is not longer used, it has been replaced by a merge with the previous getValue (which is called now 'get'). I tried to respect E4 context method signature. Tracking changes in above widgets was a case I did not think about. that's a good point.
You should get the latest version from CVS (sorry, the p2 site is not available yet :-( )

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

You are right, it seems that only add and remove of entries actually generate events. It's easy to add this, by subclassing the EMap implementation (e.g. override the didModify method). I think it's best to model it as a Map and hide how it's implemented as a list.

Yes it is an option,  but a collection of ContextContent is an information easily understandable to who will read the metamodel.

=>In wazaabi, the first time you display the UI, the 'refresh' event is
sent to every widget (including of course, the top level one).

So to an event handler, this event will "look like" a normal UI event (generated by the user). Sounds like a nice place to hook in initialization.
Yes, I am thinking about a 'close' like event too. Another point, I am not sure to keep this name, since I need to validate it under SWING and others. It is actually a detail, but may be something like 'core:refresh'

pmf-dev mailing list