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 :-(
1. Problems with current Modeler
===========================
- Model:
To me the main stumbling block in the current design is the "model"
part of the MVC. Using real objects (such as DataNode, DataDomain)
bound as a model to the screens was probably a mistake. Such objects
have their own behavior (and we go a long way to suppress it), and do
not allow arbitrary additions needed to make UI integration easier.
Using wrappers on top of "real" objects may be a solution, but it
doesn't strike me as a particularly clean one. I am more and more in
favor of the approach taken by Andriy and Natasha - use "mockup" model
objects.
- Events:
Events are too explicit - for each object there is a display event type
and there is a modification event type. It should be generic. There
should be a generic display event, and probably a generic modification
event, both using key path to the modified/displayed object specifying
its location in the model tree.
- View:
Our panels, though not very clean, are kind of OK, if they can be
switched to the new model approach. Though using Scope would
significantly simplify the process of creation the bindings from the
model to the form widgets and eliminate most of the explicit event
processing (such as combo box selections, or text field entry).
2. Suggested Architecture.
======================
I haven't figured one all the way, but I am looking into it. Some of
this is reflected in HRSwingBrowser in my sandbox, e.g. in one of the
CVS snapshots here:
http://objectstyle.org/downloads/cayenne/cvs-snapshots/ . Though it has
lots of garbage in it... there was/is lots of trial and error...
Anyway, if anyone has any good architecture ideas that address the
issues above, please post them here!! For now I am working in the
following direction:
For the model and events I am looking into something that follows Scope
pattern of HMVC (hierarchical MVC). For each panel there will be an MVC
class triad, with submodels being branches of a common project model
tree. One aspect of Scope models that I find useful is propagation of
model events (such as property change events) from submodels to their
parent models, all the way to the top. So for example if we change a
leaf (like ObjEntity.name), a listener of the project (project is an
ancestor few levels up from ObjEntity) will receive this event and can
do things like updating top frame "modified" status, etc. In other
words, events follow model hierarchy, instead of having a central
mediator object for all events (our current EventController). This
assumes the tree-like model. Not sure if this creates loops with other
graph topologies...
This will require a creation of our own project model. At least for
access classes such as Configuration, DataNode, DataDomain. Likely we
can reuse the objects from the map package (though Andriy decided to
create substitutes for them as well). At some point we started wiring
events into the map package. We can do it more consistently now.
On the presentation side we should totally use JGoodies forms, and
actually this is the only part that does not require a rewrite :-)...
3. Review of Scope Framework
http://scope.sourceforge.net
=========================
General feeling is that Scope is good and makes lots of things easier,
but it also has serious limitations and doesn't make it easy to extend
it. The documentation is close to non-existent, and I had to figure
out lots of things from the source code, which is usually a bad thing,
and leads to misconceptions. I guess we may or may not use Scope, maybe
just use some of its ideas...
Scope is Good:
- It allows to bind model properties to the UI widgets. No need to
register as a listener for text field or combo box events. This reduces
the "view" code like 3 times.
- It provides a standard pattern for each panel - an MVC triad of
classes with predefined responsibilities. Makes resulting code very
clean and consistent.
- I18n and property file configuration of actions and other elements
out of the box.
- It has nice validation support, with validation hooks invoked when
the binding is pushed from the form field to the model. Lots of things
are automated, such as
string to number conversions, etc.
Scope Is Bad:
- In general it is very rigid and doesn't allow much extension. Most of
the methods are final, most of the ivars are private. Events do not
extends EventObject and Listeners do not extends EventListener (so
Cayenne EventManager could not support Scope ModelEvents).
- Porting a non-Scope model to a scope application in general proved to
be a real pain (you can see that I had to roll out my own active model
in HRSwingBrowser). I guess I need to investigate some their version of
Key Value Coding - a PropertyManager. Looks like it supports some
customization.
Andrus
This archive was generated by hypermail 2.0.0 : Sun Nov 30 2003 - 20:32:09 EST