[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: EMF backed Workbench (Was Re: [eclipse-incubator-e4-dev] Initialdiscussion on the 'modelled' workbench UI)
|
Ed Merks schrieb:
Yves,
These are very pretty! It's sure nice to be able to understand the model
from a simple picture to truly appreciate its simplicity.
I personally like to see a model with the inheritance and associations all
in one picture so it's easier to know associations that are available as a
result of inheritance. Of course it can get cluttered and is more
difficult to render...
Tom,
Because Java doesn't support multiple class inheritance, when EMF is
generating an Impl class, it will pick the Impl class of the first
ECass.eSuperTypes as the class it extends and then mix-in the other
implementations for additional eSuperTypes. For this reason, it's best to
Ok, I've already a little todo list and I'll add it there. Should be a
cheap change :-)
use EStyle as the first eSuperType of EStyleClass and EGUIModelElement as
it avoids the duplicate code for all the style features and their
accessors. As Marcelo mentioned, it's kind of gross to use EBooleanObject
(java.lang.Boolean) instead of EBoolean (boolean), but I know you wanted to
match the starting model closely. The same comment applies for
EIntegerObject. Given how many booleans there are in this model, using
primitives along with the generator option to pack them into bit fields
will save like 28 bytes per instance (and more for derived types with yet
more booleans). The new option in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=226815 would allow the enum
value to be packed away for yet another 4 bytes of saving per instance.
Compared to a map-based implementation, the memory footprint would be
dramatically smaller with this more structured approach.
On the list :-)
I'm curious about the intended distinction between EStyle and EStyleClass?
It it also good that a GUI Model Element is a Style rather than has a
Style? It will save many objects to take that approach, so it's probably a
good thing, but it makes me wonder why not just merge EStyle and
EStyleClass and have EGUIModelElement extends the merged result? I've
never been a big fan of multiples with multiple inheritance.
The reason is that Eric's model also works like this :-) I think the
reason is HTML inspired where an element has an attribute (e.g. bgColor)
and a style associated with it which also has an attribute bgColor.
--------8<--------
<style>
.colorMe {
bgColor: #F00;
}
</style>
<td bgColor="#0F0" class="colorMe">
--------8<--------
So in this setup td#bgColor is the attribute UIElement inherits from
EStyle and the value td#class#bgColor is the attribute EStyleClass
inherits :-)
As discussed in another thread with Yves in the final solution we remove
the bgColor at the element level (just like HTML's div/span elements who
don't have ui-attributes associated with them) we must ensure in our
UIElement that when somebody does:
UIElement#getStyle()#setBgColor() doesn't change the original style but
only the local "copy" the UIElement-Instances holds. Cloning the
style-instance when it is set on the element is the brute-force way.
The next thing I'd like to address though is the registering of all the
EContentAdapters into the model. I'd like to register ONE
EContentAdpater and let the factory listeners register themselves there.
This also make debugging much easier because there's one central point
where all events flood through :-)
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
