Re: On the future of WO (here we go again)
Re: On the future of WO (here we go again)
- Subject: Re: On the future of WO (here we go again)
- From: Gino Pacitti <email@hidden>
- Date: Wed, 20 Mar 2019 09:35:25 +0000
Are there any examples of the usage showing userinfo v annotations - is like to
move butcwoukd really like to see an implementation
Is there sufficient documentation on github?
Sent from my Apple iPhone 7 plus
> On 20 Mar 2019, at 02:55, Faizel Dakri <email@hidden> wrote:
>
> Hi Andrus,
>
> Thanks for the pointers. It’s been a little while since I looked at moving to
> Cayenne, so this is good information. I think I might try going the
> annotations route or settle on interfaces, as Hugi suggested (I already do
> something like that, however it is driven from the EOModel userInfo when
> generating my parent _EOEntity classes). In any case, it is good to know that
> the foundations for metadata support is there if needed.
>
> Regards,
>
> F
>
> --
> Faizel Dakri
> email@hidden
>
>
>
>>
>>
>> On Mar 19, 2019, at 06:54 AM, Andrus Adamchik <email@hidden> wrote:
>>
>> Hi Faizel,
>>
>> FWIW, Cayenne actually supports various custom metadata in the model. There
>> is a generic extension mechanism that allows any tool (CayenneModeler, class
>> generator, etc.) to embed and read stuff in the project XML that is not a
>> part of the main schema, that can be associated with specific model objects.
>> Some examples where we use it internally:
>>
>> 1. Cayenne 4.1 (that just went beta the other day) allows to embed
>> "dbImport" tool information in XML. It is used to keep your model in sync
>> with incremental DB changes.
>>
>> 2. (Perhaps more relevant) 4.1 also has a "comment" field for every object,
>> editable in the Modeler, that generates <info:property> tags in an
>> alternative namespace. E.g.:
>>
>> <obj-entity name="Artist"
>> className="org.apache.cayenne.testdo.testmap.Artist" dbEntityName="ARTIST">
>> <obj-attribute name="dateOfBirth" type="java.util.Date"
>> db-attribute-path="DATE_OF_BIRTH">
>> <info:property
>> xmlns:info="http://cayenne.apache.org/schema/10/info"; name="comment"
>> value="attribute comment"/>
>> </obj-attribute>
>> <info:property xmlns:info="http://cayenne.apache.org/schema/10/info";
>> name="comment" value="test comment"/>
>> </obj-entity>
>>
>> 3. Cayenne 4.2 includes class generation settings in the model.
>>
>> So the mechanism to extend project metadata is there. Using it to your own
>> ends is still a bit challenging. The API is somewhat obscure. So my advice
>> would be to look at the alternative designs. But if they prove
>> unsatisfactory, we'd welcome a discussion about further extensions on
>> Cayenne dev@ list. We are almost there and if someone makes this feature a
>> priority, there's a straightforward road to implementing it.
>>
>> Andrus
>>
>>
>>> On Mar 18, 2019, at 7:50 AM, Faizel Dakri <email@hidden> wrote:
>>>
>>> Hi Maik,
>>>
>>> In your conversion from EOF to Cayenne, did you have any issues with
>>> metadata embedded inside your EOModel userInfo dictionaries and if so, how
>>> you did you go about solving them? I’ve been looking at Cayenne as a
>>> replacement for EOF and one roadblock I am running into at the moment is
>>> support for a userInfo type structure in the Cayenne datamap. Admittedly,
>>> it’s been about 6 months or so since I’ve looked, but from what I could
>>> tell, this appeared to be an open issue with Cayenne. It looked like there
>>> might be some idea on how to implement it at one point, but I did not see
>>> any resolution or implementation of it.
>>>
>>> I make extensive use of the EOModel userInfo dictionary (primarily on
>>> entities, but also on properties) to identify things that are configured at
>>> runtime. For example, I have a key named “taggable” that drives the
>>> template generation of my _EOEntity.java files. I also use userInfo
>>> entries to specify information for my auditing framework (e.g. being able
>>> to specify whether or an entity is audited, which keys to audit, etc.) or
>>> my custom filtering framework (e.g. to be able to turn on custom searches
>>> for an entity and to identify the keys that can be used in custom
>>> searches). These are just a few examples. My current thinking is to
>>> separate this metadata from the model and move it into its own
>>> configuration file, but that opens up the risk of the metadata getting out
>>> of sync with the model. It also seems a little dirty to me.
>>>
>>> Curious if anyone else is in a similar position, or has already solved such
>>> an issue?
>>>
>>> Regards,
>>>
>>> F
>>>
>>> --
>>> Faizel Dakri
>>> email@hidden
>>>
>>>
>>>
>>>> On Mar 15, 2019, at 10:18 AM, Maik Musall <email@hidden> wrote:
>>>>
>>>> Hi Mark,
>>>>
>>>> In 2017, Hugi and I converted a large project (>800.000 lines) from EOF to
>>>> Cayenne, within a few months. Had parallel branches for a while and then
>>>> switched in production, never looked back. Cayenne is similar enough that
>>>> most of the work is either boilerplate conversion or actually making use
>>>> of the newly-gained benefits. Very few hard problems encountered, and all
>>>> solved.
>>>>
>>>> Let's have a talk in Frankfurt about what your EOF specifics actually are.
>>>>
>>>> Maik
>>>>
>>>>
>>>>> Am 15.03.2019 um 15:34 schrieb Morris, Mark <email@hidden>:
>>>>>
>>>>> Just to throw our 2¢ in, we have an extremely large codebase that is very
>>>>> heavily invested in EOF, using it in several ways that dive deep into its
>>>>> bowels. ;-) Of course, we also use the WOF part of WO, and all of Wonder.
>>>>>
>>>>> Regards,
>>>>> Mark
>>>>>
>>>>>> On Mar 15, 2019, at 5:51 AM, Hugi Thordarson <email@hidden> wrote:
>>>>>>
>>>>>> Hi all.
>>>>>> In preparation for the coming WODay in Frankfurt, I'd love it if you'd
>>>>>> be open to having a discussion on the status and future of WO, so we can
>>>>>> enter the coming work prepared.
>>>>>>
>>>>>> I'd like to begin by sharing my own thoughts on the matter, based on my
>>>>>> current stack and experience. It's a rehash of something I posted to our
>>>>>> Slack yesterday, may sound revolutionary and will no doubt be
>>>>>> controversial, but I think some outside-the-box thinking is required at
>>>>>> this time. This is lengthy, sorry about that…
>>>>>>
>>>>>> --
>>>>>>
>>>>>> In the past few years I've been working towards minimising the use and
>>>>>> effect of WO/Wonder on my stack, so when and if The Time comes, I and my
>>>>>> customers have a migration path forward. Among the things I've done is
>>>>>> move from EOF to Cayenne and from Ant to Maven (to make using 3rd party
>>>>>> jars, including Cayenne easier), both of which have turned out to have
>>>>>> been very happy decisions which I wholeheartedly recommend, regardless
>>>>>> of anything else you do.
>>>>>>
>>>>>> I love working with my WO/Cayenne stack, which is currently only
>>>>>> "polluted" by the following frameworks:
>>>>>>
>>>>>> -- WO:
>>>>>> * JavaFoundation (indirectly through WO, I never use foundation classes
>>>>>> in my code unless absolutely required by WO)
>>>>>> * JavaWebObjects
>>>>>>
>>>>>> -- Wonder (I consider Wonder "polluted" since it depends on WO/EOF)
>>>>>> * ERExtensions (only the WO stuff, not the EOF stuff)
>>>>>> • Ajax
>>>>>> • WOOgnl (indirectly for parsing Wonder-style inline templates)
>>>>>> …and of course then there's the deployment stuff (JavaMonitor,wotaskd,
>>>>>> adaptors).
>>>>>>
>>>>>> Given this, here's my proposal for a way forward:
>>>>>> * We abandon EOF (and, in fact, any ORM—this is not meant to be a full
>>>>>> stack effort, initially at least)
>>>>>> * We re-implement JavaWebObjects as required (and the absolutely
>>>>>> necessary parts of JavaFoundation, such as KVC and NSBundle) as a single
>>>>>> framework
>>>>>> * We separate the necessary WO stuff from the EOF/D2W stuff in Wonder
>>>>>> (as well as other totally unrelated things like mail sending frameworks,
>>>>>> other utility frameworks and "useful applications") and include it in
>>>>>> our re-implementation
>>>>>> * We create a fork of WOLips that knows how to live within the New
>>>>>> Universe
>>>>>> * We rule the world
>>>>>>
>>>>>> Ideally, what we end with is Just a Web Framework™ with IDE integration
>>>>>> (and nothing else) that can serve as a basis for future development.
>>>>>> While re-implementing WO may sound like a huge undertaking, I actually
>>>>>> think it's smaller than rewriting all of my solutions that depend on it.
>>>>>> This probably applies to more of you.
>>>>>>
>>>>>> Now, looking at my own stack I know this proposal might sound a bit
>>>>>> self-serving, but I'd like to hear other opinions. I believe it's a
>>>>>> realistic way forward with (comparatively) minimal development effort.
>>>>>> Turns out that WOF itself is the only part of the WO/Wonder stack that I
>>>>>> really just don't want to live without.
>>>>>>
>>>>>> This is something I'd like to do, and if anyone likes the idea and is
>>>>>> willing to participate, I'm confident we can make this work! Doing stuff
>>>>>> alone sucks.
>>>>>>
>>>>>> Cheers,
>>>>>> - hugi
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden