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 <list...@dakri.com> 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 > list...@dakri.com > > > >> >> >> On Mar 19, 2019, at 06:54 AM, Andrus Adamchik <and...@objectstyle.org> 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 <list...@dakri.com> 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 >>> list...@dakri.com >>> >>> >>> >>>> On Mar 15, 2019, at 10:18 AM, Maik Musall <m...@selbstdenker.ag> 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 <mark.mor...@experian.com>: >>>>> >>>>> 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 <h...@karlmenn.is> 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 (Webobjects-dev@lists.apple.com) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/mark.morris%40experian.com >>>>>> >>>>>> This email sent to mark.mor...@experian.com >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/maik%40selbstdenker.ag >>>>> >>>>> This email sent to m...@selbstdenker.ag >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/listfez%40dakri.com >>>> >>>> This email sent to list...@dakri.com >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/andrus%40objectstyle.org >>> >>> This email sent to and...@objectstyle.org >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/listfez%40dakri.com >> >> This email sent to list...@dakri.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/ginokris%40mac.com > > This email sent to ginok...@mac.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
