Re: eomodeler game plan

From: Mike Schrag (mschra..dimension.com)
Date: Thu Jul 13 2006 - 11:20:07 EDT

  • Next message: Pierre Frisch: "Re: eomodeler game plan"

    We can't include WO libraries in the WOLips distribution because of
    licensing, so it would require having users copy WO jar files into
    plugins after installing. I think it would suck from a workflow
    standpoint. But yeah, SQL generation is one of the nastiest things
    so far ... I'm also not quite sure if the table creation code is in
    the WO libs or in EOModeler's private frameworks. I've never
    actually done that from within WO itself.

    ms

    On Jul 13, 2006, at 10:29 AM, Pierre Frisch wrote:

    > Just one question? Why not use WO for sql generation? It works very
    > well and I have lots of experience with it. All my projects create
    > their own DB structure if it does not pre-exist. It would have the
    > benefit of consistency.
    >
    > Pierre
    >
    > On 13-Jul-06, at 4:16 AM, Mike Schrag wrote:
    >
    >> For the curious, here's my tentative plan for EOModeler:
    >>
    >> Pretty Much Done
    >> * data model (reading, writing, loading dependent models,
    >> prototype support, etc) including notifications (for syncing UI
    >> components as it changes)
    >> * model browser (== 'tree view in EOModeler)
    >> * entity browser (== entity list table in EOModeler)
    >> * attribute browser (== attribute list table in EOModeler)
    >> * relationship browser (== relationship list table in EOModeler)
    >> * relationship editor (== relationship inspector in EOModeler)
    >> * user info editor (shared among several object types in inspectors)
    >> * java generation (wolips integrates with EOGenerator for java
    >> generation)
    >> * entity editor (excluding stored procs)
    >>
    >> Phase 1.0 To-Do's (sure things for WWDC)
    >> * adaptor info editor
    >> * attribute editor
    >>
    >> Phase 1.1 To-Do's (pretty must essential, but might be annoying)
    >> * SQL generation (this is the big one -- I'm hoping to be able to
    >> use Cayenne's code for this) -- It's the trickiest because it
    >> requires the eclipse plugin to talk to a JDBC driver that isn't in
    >> its own classpath (it's in the project's classpath). This is the
    >> one I'm least looking forward to :)
    >>
    >> Phase 1.2 To-Do's (really nice to have, but not technically
    >> ESSENTIAL)
    >> * fetch spec editor
    >> * flattened relationship editor
    >>
    >> Phase 2 To-Do's (probably post WWDC)
    >> * stored procedure browser/editor/etc
    >> * diagram view (Eclipse has the Graph Editing Framework (GEF) that
    >> should provide most of this, but I'm pushing it off for now)
    >> * sql data browser (though if i can do generation, this might not
    >> be a big deal)
    >> * schema syncing
    >>
    >> ms
    >



    This archive was generated by hypermail 2.0.0 : Thu Jul 13 2006 - 11:20:14 EDT