This solution is basically like the third approach. It makes some assumptions about the user model that may not be true. The user (God forbid) might have a compound primary key for instance. It that case, the relationship wiring falls down and needs adjustment. So, the join info becomes another property. I guess the logical end there is to have the entire relationship model is in the properties.
After giving this more though, I think ultimately what I want is like a hybrid between #1 & #3. I should still create the AppBusinessLogic framework, because different apps may dictate different logic. Going back to the original example, a user may own an address book in one app, may be permitted to edit a master address book in another app, and may be able to have multiple address books in a third. I can't know that in either framework. The application dictates those needs. That being the case, then I would want to create the business logic framework, but I would need to do the dynamic relationship wiring in the glue layer. So what you're doing Kieran... but in the reverse direction. I also think it would be better if this dynamic relationship were stored in the model, not in properties. Sure, properties can work, but they're clumsy for this purpose. I think a good solution would be to add a "dynamic relationship" checkbox into the relationship editor whenever cross-model relationships are made. The relationship characteristics could then be stored in the userInfo dictionary of the relationships destination entity. Then we could make ERXEntityClassDescription look for those and set them up whenever it creates the class description for the entity. No model hacking or entity code required. Sorta like the ERXInverseRelationshipName key on steroids. I wonder if that would be workable. It would require more model scanning at startup. Ramsey On Apr 25, 2012, at 4:37 PM, Kieran Kelleher wrote: > 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/ramseygurley%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]
