Re: eomodeler game plan

From: Mike Schrag (mschra..dimension.com)
Date: Thu Jul 13 2006 - 12:03:38 EDT

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

    So based on the email you sent, it sounds like licensing isn't really
    an issue ... Interesting. Well, I needed to clean room the EOModel
    files to do notifications properly, so I don't feel TOO bad that I
    ended up rewriting all that. I suspect it would have been really
    tricky to try and wire up the current models to make the active
    update the UI. However, now we have two model sets that we need to
    go between. It may be that we require the user to save their model
    before SQL generation, and just reload the model again using EOF proper?

    ms

    On Jul 13, 2006, at 11:45 AM, Pierre Frisch wrote:

    > But there are no licensing issue anymore. We can redistribute a WO
    > developed product freely since WO 5.3 and WOLips is no exception.
    >
    > If we decide to use WO I could probably do my share. I am on
    > "holiday" for 10 days so I can have a look at it. The table
    > creation is part of EOF public API and is supported by all Databse
    > plug-ins. I also have a library for index creation that is one of
    > the bug missing feature of EOModeler.
    >
    > Pierre
    >
    > On 13-Jul-06, at 8:20 AM, Mike Schrag wrote:
    >
    >> 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 - 12:03:46 EDT