Sure, here you go. https://github.com/kierankelleher/WebObjectsIncubator
On Apr 25, 2012, at 5:33 PM, Henrique Prange wrote: > Hi Kieran, > > On 25/04/2012, at 16:12, Kieran Kelleher wrote: > >> 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. >> > > Any chance to add it to GitHub? > > Cheers, > > Henrique > >> >> * 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/hprange%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]
