You know that EOModeler does have an Module API (plugin) so that it may
be extended. One of the Examples shows how to do this. In fact one of
the first demos of this extensibility several releases ago was a custom
Model view called 'DiagramView'. I'm not saying this is a solution for
you ... but it is an opportunity for the community. I guess this is a
form of 'black-box open source'.
EOModeler is a developer's tool first although it has other roles. The
diagram view itself is pretty new. There are so many other firms that
do work in the OOA&D area, it seems like for most customers those
solutions will always have a lot more features. Most customers that
really care about OOA&D tools are companies that don't really balk at
that kind of $ for a design tool. Heck it wasn't that long ago that
WODev itself was $5000 per seat. So is this something that should be a
priority over better developer support (e.g. EOPrototypes, better SQL
generation, client-side class gen, and so forth that were added this go
around). It sounds like in your case from a real but also political
angle that IS what you want. And that's fine, feedback like this is
good.
> time I need to make a database change and then import the new updated
> model and then make all my relationship changes again and regenerate all
Why do you have to make relationship changes? Do you mean that you
typically find that the FKs and PKs are changing a lot under you? You
know you can copy and paste attributes and entities and relationships
around. However if what you want to do is the reverse, add a column in
the Model and push that to the DB, well, that requires you to buy a beer
for your DBA (unless you don't mind dropping and creating the table).
> model and then make all my relationship changes again and regenerate all
> affected java again (but maybe I'm just not good at using the tools yet -
Personally I don't like all those pesky accessor methods on my EOs. I
tend to use EOGenericRecords whenever possible. My Java EOs have ONLY
their ivars and businesslogic. Zero accessors. This works BTW. The only
price is that instead of doing: firstName() you have to do
valueForKey("firstName"). But what I gain is that I basically never have
to regen a class, just add/remove the ivar for the EOAttributes that
changed. Of course if you do have to merge changes, the FileMerge
utility is a pretty cool way to do it.
d
"Melody M. Alfather" wrote:
>
> On Thu, 18 Mar 1999, David Neumann wrote:
>
> > ... Why not just continue to use ERWin for your
> > diagram documentation if that is meeting your needs?
> >
>
> Because ERWin costs $3000 for ONE developer license and WebObjects and
> Oracle's Designer (2000) are essentially free to our university community
> aand the university of michigan's information technology division doesn't
> believe in purchasing the best tool no matter what the cost.
>
> I'm surprised with the 10 year or so maturity of the EOModeler tool (which
> I've been touting), there hasn't been an acceptable level of progress with
> respect to showing management what's been created with it (i.e. nice
> pictures). Even let me export to visio format or something (that's only
> $99 for UM community too) - that what at least there's a non-os-level
> solution. I think the tool is great at what it does....well, actually, I
> think it's great at almost everything it does - I'd like it to be better
> at incorporating database changes into an existing model. I shudder every
> time I need to make a database change and then import the new updated
> model and then make all my relationship changes again and regenerate all
> affected java again (but maybe I'm just not good at using the tools yet -
> certainly I wish my customer would have let me take the time to design the
> entire db up front - but he's much more into rapid prototype mode where we
> get incremental results quickly).
>
> Mel
