I totally agree that Modeler is confusing and hard to modify. I said it
all along, since I was the first one to feel the pain of the original
"hit-and-run" Modeler design. A few months ago I grew so desperate with
it, that I started investigating various alternatives (incuding writing
an Eclipse plugin). So let me elaborate on my vision of the Modeler
development a bit.
I think we should do a full conversion to Scope (maybe in 1.1 or 1.2). I
picked Scope, since it workes with very well Swing instead of
reinventing it, allowing key-value coding and lots of other nice things
that help to reduce the amount of code. The most important thing about
Scope though is that it provides a development pattern for the whole
application (something that Swing doesn't provide).
Hopefully using Scope will allow us to get rid of *all* map modification
events. Scope uses hierarchies of MVC triades and allows event
propagation (scope-specific events are called Controls) along the
hierarchy. Needless to say that in many cases it modifies the underlying
model without any events.
I haven't done the full switch yet (only a few recent panels are
implemented using Scope), since I feel like Modeler in its current form
has an acceptable level of quality for the end users and is ready for
1.0. I did not want to break it apart and face the task of rebuilding it
from scratch, thus delaying the 1.0 date further.
As a downside, I stopped any attempts to optimize events and other
things till the switch is done. 1.0 is the most important thing now!
Andrus
Holger Hoffstätte wrote:
> Dear chili heads :-)
>
> I've been trying to fix various aspects of both Modeler and the underlying
> core, and have noticed that a lot of code in Modeler is concerned with
> keeping the DataMap/Entity/Atribute/Relationship network together. For
> example get(Obj/Db)EntitiesAsList constantly creates new Lists for no good
> reason (an immutable reference could do just as well), same for e.g.
> getAttributeMap, getAttributeList, getRelationshipList etc. So I tried to
> cache these locally instead of constantly recreating them.
> Maintaining/invalidating these caches needs to be done too, since e.g.
> getPrimaryKey() needs to be updated when e.g. an externally gotten
> DbAttribute has changed to be a PK (clicked in Modeler) etc., so I added
> attributeChanged() and relationshipChanged() to Attribute and
> Relationship, have these called from any setters in subclasses..et voilá:
> cache coherency and no more needless List creation. Works perfectly, both
> in Modeler and a commandline-fetch app.
>
> It then dawned on me: I've basically reinvented modeler.event.DB/ObjEvents
> - badly. :}
> Obviously it would be much better to move the non-display related events
> to the core package, no?
>
> This would make Modeler a lot smaller, easier to refactor (and it _does_
> need some serious cleaning; it is really confusing and hard to modify
> right now..sorry Andrus ;)
and also give a nice way of dealing with
> dynamically added Relationships, Attributes etc. in the core framework -
> think about the "select count(*)" trick of adding a derived attribute
> dynamically. Any on-thy-fly reconfiguration would become a lot easier,
> because the network can start to maintain itself instead of having to be
> kept in order externally. Also would make a lot of repeated
> traversing/rebuilding of internal data structures unnecessary.
>
> Does this sound like a good idea? If so, any volunteers? :->
>
> Holger
This archive was generated by hypermail 2.0.0 : Sun Mar 02 2003 - 13:41:17 EST