[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] Modelled UI change notification - live model
|
Maybe some background informations on move operation. To distinguish
this operation from a remove:
- Remove: The containment-parent is null
- Move: The containment-parent is the element the moved element is the
child of => Without containment with don't know if it is a move
or a remove
Maybe a small example makes this clear:
Person
+ addresses: Collection<Address>
Address:
+ person: Person
You see this a Bi-directional relationship made which is simply the
explict expression of a containment.
Person source = new Person();
source.getAddresses().add(new Address());
source.getAddresses().add(new Address());
Person target = new Person();
// Solution A for a move
target.getAddresses().add(source.getAddresses().get(0));
// Solution B for a move
source.getAddresses().get(0).setPerson(target);
// Not a solution is!!!!!
Address a = source.getAddresses().remove(0);
source.getAddresses().add(a);
Tom
Tom Schindl schrieb:
> I think the first solution in b) is not working because we have to have
> a containment relationship to identify a move.
>
> Tom
>
> Eric Moffatt schrieb:
>> Tom,
>>
>> of the two approaches you mention I'm more in favor of the first part of
>> 'b)' but the 'view' cache should be in the WorkbenchWindow rather than
>> the Workbench. This is because we need a new instance of the view for
>> each Window (they ciould both be showing the Java Perspsective). This
>> nicely captures the 'view, it's UI info (label, icon, ttip...) and its
>> implementation control in one place but allows references to it from
>> multiple disjoint hierarchies (but never twice in the same hierarchy,
>> that'd be multi-instance views).
>>
>> I'm less inclined towards the proxy approach because it makes structural
>> changes in the model when switching perspectives and it complicates the
>> model, neither of which are necessary using the first approach...
>>
>> Good point about 'move'; this has to be an atomic operation, not a
>> remove/recreate pair for the reasons you mention. Is there a way to
>> arrange the model so that we can get a single 'parent changed'
>> notification to key the UI update off of? Calculated property perhaps?
>>
>> Eric
>>
>>
>>
>> *Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>*
>> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
>>
>> 09/28/2008 10:57 AM
>> Please respond to
>> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>>
>>
>>
>> To
>> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>> cc
>>
>> Subject
>> Re: [eclipse-incubator-e4-dev] Modelled UI change notification -
>> live model
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>> One more thing on this whole topic the rest is going to the bug. The
>> critical things in are DOM are (if you compare it with an ordinary DOM).
>>
>> a) Distinguish between:
>> - Moving of nodes (e.g. moving ViewPart A from Stack A to Stack B)
>> - Removing of node (e.g. remove ViewPart A from Stack A)
>>
>> This is doable with EMF but this gives us a new headache because this
>> assumes that we have a containment-relationship (or if you are not a
>> EMF-guru a bidirectional parent-child-relationship between Stack and View!)
>>
>> b) because of a) this means that sharing View Part A in between Stack A
>> Perspective A and Stack B from Perspective B we suddendly have links in
>> our model. There are multiple ways to solve this:
>> - The views are located at another place (e.g. directly under the
>> workbench)
>> - We use links and insert Link/Proxy objects where we want share things
>> (You see this in my extended model!) between views and when a
>> perspective gets visible all proxy objects are exchanged to the real
>> view-part and at the place they got removed a new proxy with the link
>> to the real object
>>
>> Tom
>>
>>
>> Eric Moffatt schrieb:
>>> Tom, in one word "sweet!!' I'd been working on wiring up the listeners
>>> but I'm just not a databinding guru. I've just taken a look at how you
>>> are wiring up the controls/model and love it...this is a pattern we can
>>> make great use of.
>>>
>>> I'm switching over to using it but I can'tfind SWT text observables for
>>> 'Items' (i.e. MenuItem, ToolbarItem, CTabItem). I'll make a quick patch
>>> that adds them (a quick look a 'observeText' shows that this is fairly
>>> trivial).
>>>
>>> Nice one,
>>> Eric
>>>
>>>
>>>
>>> *Mike Wilson/Ottawa/IBM@IBMCA*
>>> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
>>>
>>> 09/24/2008 01:22 PM
>>> Please respond to
>>> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>>>
>>>
>>>
>>> To
>>> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>>> cc
>>>
>>> Subject
>>> Re: [eclipse-incubator-e4-dev] Modelled UI change
>> notification -
>>> live model
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> From: Kevin McGuire/Ottawa/IBM@IBMCA
>>>>
>>>> 1) Do we agree this is the behaviour we want?
>>>>
>>> I'd certainly like to see this. In particular, when we have talked
>>> publically about how e4 would be more dynamic/responsive to develop for,
>>> this was the kind of thing we had in mind.
>>>
>>>> 2) When do we we think we'd provide it?
>>>>
>>> I'd argue that it's worth thinking about it soon, since there are
>>> potentially interesting issues w.r.t. state management, SWT widget
>>> lifecycle, etc.
>>>
>>>> 3) I think I can imagine with the current code base how we handle
>>>> on-the-fly creation and deletion, but what about modification?
>>>> Right now the factories 'make', they don't 'modify existing'.
>>>>
>>> ... and if we end up with a "destroy and recreate" model, we need to do
>>> a better job of maintaining state than we currently do (e.g. it's not ok
>>> for the tree to be recreated with all the nodes collapsed, etc.)
>>>
>>> McQ._______________________________________________
>>> eclipse-incubator-e4-dev mailing list
>>> eclipse-incubator-e4-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> eclipse-incubator-e4-dev mailing list
>>> eclipse-incubator-e4-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>>
>> --
>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH
>> ------------------------------------------------------------------------
>> tom schindl leiter softwareentwicklung/CSO
>> ------------------------------------------------------------------------
>> eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
>> _______________________________________________
>> eclipse-incubator-e4-dev mailing list
>> eclipse-incubator-e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> eclipse-incubator-e4-dev mailing list
>> eclipse-incubator-e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
