Re: eomodeler game plan

From: Pierre Frisch (pierre.frisc..pearway.com)
Date: Thu Jul 13 2006 - 12:20:56 EDT

  • Next message: Mike Schrag: "Re: eomodeler game plan"

    With WO licensing I don't understand why Apple cannot make their
    intention clear -:). It is all there but you have to learn some
    bizarre legal language top understand it. I am sorry I did not step
    in before.

    Saving before SQL generation is a valid strategy. Would you like me
    to have a look into this? I have 12 hours of flight in from of me -:)

    On a practical note how do I commit? or do you want it all to go
    through you?

    Pierre

    Pierre

    On 13-Jul-06, at 9:03 AM, Mike Schrag wrote:

    > 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:21:03 EDT