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: Faizel Dakri <email@hidden>
- Date: Tue, 19 Mar 2019 21:50:29 -0500
Hi Maik,
Thanks for the information, and especially for the nudge towards using
annotations. I think I like that idea better, better than even my current
scheme of using the userInfo dictionary in the model. I don’t know how hard it
will be, or even if it will work for me, but it is definitely an avenue that
I’m going to start looking into.
Regards,
F
--
Faizel Dakri
email@hidden <mailto:email@hidden>
On Mar 18, 2019, at 9:11 AM, Maik Musall <email@hidden
<mailto:email@hidden>> wrote:
> Hi Faizel,
>
> the EOF model importer wasn't perfect. Quite a few steps on the way to
> Cayenne involve manually dealing with edge cases around the lesser-used
> features of EOF, and I suppose this is one of them. I didn't make important
> use of the userInfo dictionaries in EOF, so I can't really offer something
> from experience on that specific topic. (Maybe someone else can?)
>
> AFAIK, the Cayenne model doesn't support attaching arbitrary key-value data
> to entities, and Cayenne experts will probably point out that the model
> should be as purely that as it can be, and that other info should be stored
> elsewhere, like e.g. in Annotations on the subclasses or something.
>
> Maik
>
>> Am 18.03.2019 um 05:50 schrieb Faizel Dakri <email@hidden
>> <mailto:email@hidden>>:
>>
>> 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 <mailto:email@hidden>
>>
>>
>>
>>> On Mar 15, 2019, at 10:18 AM, Maik Musall <email@hidden
>>> <mailto: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
>>>> <mailto: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
>>>>> <mailto: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
>>>>> <mailto:email@hidden>)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>>
>>>>> This email sent to email@hidden
>>>>> <mailto:email@hidden>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden
>>>> <mailto:email@hidden>)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>>
>>>> This email sent to email@hidden <mailto:email@hidden>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden
>>> <mailto:email@hidden>)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden <mailto: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