In the absence of the fancier solution (something like partial entities), I think I would make an app variant of the entity (where the class of the app one extends the class of the framework one) and model-rewrite the non-app variant to be the app variant.
ms On May 29, 2012, at 6:22 PM, Paul Hoadley <[email protected]> wrote: > Hi Ken, > > On 30/05/2012, at 3:10 AM, Ken Anderson wrote: > >> My first question would be - how do you actually benefit from having this >> data separated? > > I don't. It's just a side effect of wanting to have an app-specific EO based > on a more general framework-level EO. > >> Is there a reason that you don't just create a new entity for the new >> project that can represent the entire organization? > > Just code/entity reuse. I already have a framework-level Organisation > entity. It's just that different applications want to be able to hang > different attributes and relationships off it. > >> If the reason is that you have code that you would typically use in more >> than one project, I would consider building that into POJOs . In general, I >> find that the benefits of splitting up entities (either through inheritance >> OR composition) seldom outweighs the benefits of having them together, >> unless there are some circumstances that totally warrant it. If you could >> provide more information on the perceived benefits, people might be able to >> help you better. > > It's basically the exact scenario described in the Javadocs for Mike Schrag's > partial entities: > >> A very common case where this becomes useful is that of a Person entity. >> Person is an entity that is used in many different scenarios, each of which >> requires additional attributes and relationships. For instance, you may have >> a task management application and you want to embed your calendaring >> framework into it. The common Person base entity may have "username" and >> "password" attributes, the tasking application may add an "activeTasks" >> relationship, and the calendaring framework may add a "scheduledEvents" >> relationship as well as "dayStartTime" and "dayEndTime" attributes. Note >> that partials are not designed to address the issue of "roles," where >> different people in the system may have different roles at different times. >> Partial entities are designed to address the issue of combining high level >> modules together to form more complex static entity declarations. > > > That's precisely the problem I'm trying to solve. Until now I've done it via > inheritance. I was going to see if composition was any easier, but after > diving into it, it seems to be about as hairy as inheritance, just in > different places. What I settled on was adding a new column to the > Organisation table using a migration, and adding a matching attribute to the > model at application startup. Apart from not having the convenience of the > Velocity template methods, it certainly seems to work fine. > > I'm still interested to know what other people are doing, though. Given the > problem described by Mike above, how are people solving it? > > > -- > Paul. > > http://logicsquad.net/ > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
