[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled' workbench UI
|
Tom,
I have to say that you're an amazing person who is always so eager to dive
right in and help. If only we had many more Tom's in the world! I'll try
to be available on skype over the weekend to help out in any way I can.
In light of that, it seems particularly cruel that I'm chuckling a little
to see folks rediscovering the joys of maintaining bidirectional
referential integrity. Keeping parent and child relations (containment)
consistent is obviously very important. Not only is it tricky to do it
right on the programmer's end of things when the programmer has to manage
it himself, which, as you say is grossly error prone. But even writing the
code to do it properly within the model is surprisingly tricky to get right
even just once.
Consider that if you move an object from one parent to another how many
pointers need to be swizzled correctly. It's even worse if a feature is
single valued. For example, a perspective might be allowed only one main
menu. Generically, setting an object y into a single valued containment
reference r of x could involve all the following. Removing x's current "r"
object, making sure that object has its parent x set to null, removing y
from its current parent object , making sure that parent object's reference
to y is cleared, setting y to point at x , and setting x to point at y.
Can we really expect a user to do this right each time? Absolutely not!
Can we expect model implementers to hand write code that will do this
correctly for each new feature "r" he implements? We could, but I bet
they'll be unhappy and screw it up regularly. In fact, I'll leave it as an
exercise to the reader to think about how to manage all the above steps
properly. When you're done with that, for bonus points, think about the
need to produce notifications describing what's been changed without
overlooking the fact that no one will want to be notified while the model
is in an incomplete intermediate state between the start and end states...
Of course you've also run into the nasty problem of discovering what
properties are sensible in any given context---where's the meta data to
tell you that? And also, given a property, which type of thing does it
denote? I.e., what kind of value can I set to it. Again, where's the meta
data to tell you? And of course, without a generated API, there's no JDT
help with name completion based on statically typed objects nor are there
statically typed return values. You'd just need to read a lot of
documentation, write lots of instanceofs, and most likely end up with a
lot of runtime failures before you get it right.
I should quit while I'm way behind. It reminds me that I've been accused
of coming into a room with a fire hose turned full blast. Sorry about
that! I can't help it. I thought there was a fire...
These are of course all the kinds of issues that EMF will solve directly.
I understand now that Eric's model is effectively like SDO's DataObject or
EMF's EObject and that the only form of meta data is named features. In
other words, there's a reflective API, a tiny bit of meta data, but not
meta model It is certainly very simple and hence is an excellent starting
point in terms of starting with the smallest of all possible models.
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Tom Schindl
<tom.schindl@best
solution.at> To
Sent by: E4 developer list
eclipse-incubator <eclipse-incubator-e4-dev@eclipse.o
-e4-dev-bounces@e rg>
clipse.org cc
Subject
04/04/2008 12:22 Re: [eclipse-incubator-e4-dev]
PM Initial discussion on the
'modelled' workbench UI
Please respond to
E4 developer list
<eclipse-incubato
r-e4-dev@eclipse.
org>
[...]
> I'm going back to bed, I'm under the weather today. Tom, let me know if
> there's anything I can do...Monday...
>
I have plenty of them but I think they are better discussed on IRC ;-)
One thing I'm not sure is if this is a bug or I don't understand your
model correctly but take this code:
--------8<--------
1 // Client Area
2 ModelElement clientArea = new ModelElement(GuiModel.FID_CLIENT,
"Client Area"); //$NON-NLS-1$
3 wbwModel.setProperty(WBW_CLIENT_AREA, clientArea);
4 clientArea.setProperty(ModelElement.ME_PARENT, wbwModel);
5 wbwModel.addElement(ModelElement.ME_CONTENTS, clientArea);
--------8<--------
Why do you restore the clientArea-instance as an attribute in your model
and as ME_CONTENTS? In fact code line 4 is senseless if your current
code is correct because ModelElement#addElement() by definition updates
the parent :-)
Another thing I'm not happy with are that I need to take care myself
that the parent-child relationship is up-to-date all the times myself.
This is going to be a steady point of failure where one forgets to
update one side and are left with a non bidirectional model although in
theory it should be one :-(
I'm talking about code like this:
--------8<--------
wbwModel.setProperty(WBW_TOP_TRIM, topTrim);
topTrim.setProperty(ModelElement.ME_PARENT, wbwModel);
--------8<--------
Couldn't you simply check inside setProperty() if the given value is a
ModelElement and update the parent automatically?
Another problem I am facing with this admitedly small model is to
extract which property has meaning for which "ModelElement-Type". Which
properties does Perspective-ModelElement support, which of them is a
String, Integer, ModelElement, ... .
Hope you feel better on Monday or did played Pool to long last night :-)
Tom
--
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
