Have a Principal class in the "pluggable framework" that looks for a (runtime) properties that define a relationship destination (1) entity name, (2) primary key attribute and (3) relationship name and then dynamically create the relationship at startup time.
I have an example framework that demonstrates this, ERRoleBasedAccessControl*, that I created a while back but have not had time to fully integrate it into a production app yet. I can send it to you if you are interested in this approach. * ER prefix = was thinking of eventually committing to Wonder if it turned out to be useful enough and after production usage for a while. On Apr 25, 2012, at 2:27 PM, Ramsey Gurley wrote: > I'm just wondering what others are doing... > > I'd like to create frameworks that are independent and snap together with the > least amount of work. > > A contrived example: Say I want a user framework, an address book framework, > and a calendar framework. Each framework provides functionality > independently. If I start an app with just the address book, then I can add > and remove entries in one master address book. If I start an app with just > the user framework, I can add/remove/login users. But if I use both, now I > want to have one address book per user. > > I don't just want to create a relationship from address book to user, because > that ties the two frameworks together. I'd like the address book framework to > work with or without users. I don't want to create a relationship from the > user to the address book either, for the same reason. Maybe I want to build > an app later that needs users, but not address books. > > It seems the traditional way is to build all the frameworks, then build the > glue code into an AppBusinessLogic framework. In that framework, I would > create some kind of join table like UserAddressBook. That way I keep the > dependencies separate from the frameworks... but then maintaining all the > glue code becomes a tedious chore. If I make two or three apps with address > books and users, I'm duplicating this "BusinessLogic" framework logic to the > point where it becomes a lot of work and parallel code bases. > > I looked at ERXPartials. That looks brilliant, but it has a big > *experimental* stamp on it and I've never heard of anyone using it, so I'm > wary. > > Another approach is to implement a lot of this glue logic in the frameworks, > but enable/disable things in properties or the framework's finish > initialization. This reduces the redundancy of creating glue frameworks. > This has it's own pitfalls. I have to wire up relationships at startup based > on whether or not some property is set. I also get none of the convenience > that comes with the eogen stuff and ERXKeys for those relationships. > > Any approaches that I've overlooked? > > Ramsey > _______________________________________________ > 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/kelleherk%40gmail.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]
