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/archive%40mail-archive.com This email sent to [email protected]
