On Nov 30, 2003, at 8:32 PM, Andrus Adamchik wrote:
> Hi,
>
> Just wanted to share some thoughts on CayenneModeler design.
>
> Every time I have to change/add a feature to it, I am stumbling on its
> rigid design. Lately I was investigating various options to change
> that, looking at Andriy's DVModeler, Scope and other things. While I
> think I am onto something, I still don't see a gradual switch path,
> all my ideas mean a full rewrite :-(
After I sent the original message I was doing some more prototyping
myself, and discussed the options with a few people off this list. Here
is an update on CayenneModeler2 prototype that is checked in to my
sandbox. It was done before most of the discussions had taken place, so
it still overlooks certain things that we've solved:
The design of the prototype uses its own set of Scope-enabled MVC model
classes for the Project, DataDomain, DataMap and DataNode, and I plan
to use some sort of wrappers for things like ObjEntities. Here is good
and bad things I ran into when doing the prototype:
1. (+) I could implement scope-specific event propagation along the
object tree. This works VERY nice when we need to update a set of
unrelated widgets when something changes. E.g renaming a DataDomain
updates the top bar of the project to show that project was modified,
and also renames the node on the left-hand tree - all very clean
without a central mediator object that we used before. Each widget
simply listens to changes of its specific part of the model.
2. (+) I could build the model objects that are EASY TO USE in the
view. E.g. instead of displaying a list of DbAdapters we can build a
model that displays standard adapters in a combobox as user friendly
names (e.g. "Oracle Adapter" instead of
"org.objectstyle.cayenne.dba.oracle.OracleAdapter), but allows to check
a checkbox for "custom" adapter, and type its name in a separate field.
This applies to many other cases where we can make UI more friendly
simply by having a model that looks a bit different from the Cayenne
object. Another important case is storing any given tree node children
in a list instead of a map (most Cayenne objects store their children
in a map keyed by name) - this would allow to stop worrying that
duplicate names will break everything.
3. (+) Not using Cayenne objects directly in each panel doesn't force
us to mess with them for the GUI sake. This is very important. E.g.
DataNode is an object that maintains a bunch of DB connections.
Currently we are making a big effort to suppress any attempts to
connect from the modeler. It would be nice to avoid dealing with it at
all.
4. (-) Bypassing Cayenne objects means reimplementing lots of existing
logic, like loading and saving XML for instance. It was easy to do with
loader and saver delegates for DataNode and DataDomain, but DataMaps
don't support this level of loader customization.
5. (-) Writing an intermediate model layer is painful. It was very easy
for the access objects such as DataNode and DataDomain, but DataMap and
its children are going to be a mess. In fact (since DataMap doesn't
attempt to connect to the database and is simply a bunch of metadata),
I am planning to take an approach that would load a real data map, and
then wrap it into modeler model objects (this is not done yet, I am
still looking at the options).
Maybe we can get rid of (4) and streamline (5) by creating a generic
wrapping mechanism for domain objects into "model adapter" objects that
can work with Scope? Any other ideas are welcomed.
And finally Scope has so much undocumented internal behavior that it
can rival Cayenne :-). This is driving me nuts!! Once I think I figured
it all, I run into the next problem that halts my development for
another day.
Andrus
This archive was generated by hypermail 2.0.0 : Fri Dec 05 2003 - 01:43:50 EST