[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pmf-dev] [Wazaabi] Introduce dataObject attribute
2010/4/28 Hallvard Trætteberg <hal@xxxxxxxxxxx>
So, a general listening approach should handle this case, or model the key as unmodifyable.
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
Since fetchValue looks up in the hierarchy, a widget at one level may be affected by changes to a widget above (its ContextContent objects).
- 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
'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 :-( )
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.
The Context is a map, but I don't think the EMF maps could be listened
like EMF objects (changes of value for instance....)
Yes it is an option, but a collection of ContextContent is an information easily understandable to who will read the metamodel.
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.
=>In wazaabi, the first time you display the UI, the 'refresh' event is
sent to every widget (including of course, the top level one).
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'