On Mon, Nov 2, 2009 at 4:55 AM, Andrus Adamchik <andru..bjectstyle.org> wrote:
> For all its undeniable advantages, IMO the main usability issue with
> CayenneModeler is the fact that it is separate from an IDE. This "gap"
> results in the following problems:
>
> 1. Losing work context when switching between the apps:
> You have to often jump between the IDE and the Modeler. When switching, you
> lose your work context. E.g. click on a Java class name within some code,
> the class opens... Then you'd like to see its Cayenne mapping. To do that,
> you have to go to a different application, type something in a search box,
> open the entity, then tab between attributes/relationships, then look for
> DbEntity, tab between attributes/relationships again. It is too far away
> from the original Java class. I'd like to see Java/XML/Modeler
> representations of the same entity in the same view.
For me, and others here, this isn't a big deal. We are used to having
a separate modeler (EOModeler). Almost everyone here has two monitors
and it is nice having Eclipse on one monitor and the modeler on the
other. Sure, you can open up multiple windows in Eclipse, but Eclipse
is a heavy weight. We also use the WOLips plugin for our WebObjects
projects. That modeler still isn't as nice as EOModeler (no offense
to the WOLips people -- they are doing a great job) and part of me
thinks it is because it just doesn't feel right inside Eclipse (I know
-- hard to quantify a feeling). Also, with a separate modeler, it is
easier to give the model to our DBAs and business users to look at
instead of having to configure Eclipse for them.
I distinctly remember you not liking the idea of an Eclipse plugin in
the past, but you are entitled to change your mind. :-)
> 2. Manual Refresh
> When the model is saved, you have to refresh files in IDE to pick up the
> change.
I'm not convinced this is a big enough issue. I have Eclipse's
workspace set to refresh automatically and it seems relatively OK.
> 3. Class Generation:
> You need to generate classes manually on model change, then refresh files in
> the IDE. For Maven/Eclipse users cgen problem is somewhat addressed, as you
> can tie cgen to Maven, and Maven to Eclipse, so classes are generated on
> refresh. Still you have to do refresh, and then a second refresh (first
> refresh for xml, second for the generated classes - totally annoying).
I've gotten into the pattern of making model changes (saving
frequently) and then generating the schema changes (or manually
updating the DB) and then regenerating the classes. If the classes
are automatically generated, they are potentially out-of-sync with the
DB. Also, frameworks like Tapestry 5 will not automatically pick up
the class changes (live class reloading) for Cayenne changes. To me,
this feature is a wash. It saves a little bit of effort, but not a
significant amount to me.
> The best way to address the gap is to write an IDE plugin replacing the
> Modeler. There's a bunch of advantages and disadvantages to that:
>
> [good]
>
> * everything is integrated
Only if you use Eclipse.
> * Eclipse environment provides lots of built in services that we can take
> advantage of (most notably it has a built in project model), including graph
> capabilities.
>
> [bad]
>
> * not everybody's using Eclipse (e.g. Kevin mentioned he's an IDEA user).
> Supporting multiple IDE's is not realistic for us. I guess this can be
> addressed by packaging it into a standalone SWT app.
How easy is it to generate a standalone SWT application? (I'm
relatively ignorant of SWT.)
> * we'll have to support multiple versions of Eclipse, and will be dependent
> on Eclipse API evolution.
>
> [ugly]
>
> * the time we invested in the Modeler. Reproducing that in Eclipse would be
> non-trivial.
Indeed. Would it be worth the time? If re-doing it, would it be
better to do it in SWT? Netbeans (Matisse GUI Builder)? FX? SwiXML
and kin? I think before that can really be decided, we really need to
know where we want the modeler to go. It is the critical interface
into Cayenne. It is what pulls people in. The underlying ORM needs
to be solid/stable, but the GUI is the window into it.
> Or we can go with some hybrid approach of having an Eclipse plugin
> exchanging events with the Modeler. Not sure if we can make the user
> experience as nice, we'll have to support 2 tools instead of 1, and we'll
> have to support an extra messaging layer. But this is probably less work
> overall...
>
> Or we can write an Eclipse plugin in parallel with the Modeler and provide
> both as independent tools... Such internal competition will be a resource
> drain though.
>
> So nothing is free, and these are some hard choices... I am sort of in favor
> of the last one, as even an initial plugin prototype will show whether we
> can have significant usability improvements, without being a full Modeler
> replacement.
>
> Andrus
This archive was generated by hypermail 2.0.0 : Mon Nov 02 2009 - 10:24:41 EST