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