Re: Model dependencies
Re: Model dependencies
- Subject: Re: Model dependencies
- From: Henrique Prange <email@hidden>
- Date: Wed, 25 Apr 2012 18:33:57 -0300
- Authentication-results: symauth.service.identifier
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/5+juNheA2jpy4FDZyIgs7R2o7CzWCDUWLUp6kvP4dk=; b=deBiTFO9TwK8l52Plf0ZoTMMOjJerqlLip4+v6+e4RybkUojzwF1KJP+wrBc+OgQ2j pZCO2UkmYq6yPWdIrrjgxFVym4zM80oOS4lkAqvRhl22Lwv5JWLrpwX1hnCdqF2oxOnt ujoFQsikfR06F/6BBvPM/5E4mdoz4nDxNBjpz8i+ljotZFq27ZuwVtXuxqiRme3WCWtL 0YB5P7nBZwz0uJ0pNT+ifMEaGeXRnbv2j3z4VAhtpO9ifizPuu/wM3sibX2sPE/BCJ7B /DezJ1DO2XFIJRDu6VB8SGMd8dlGGkUb7qCXg9ql0IHPqkWKPvAY0E0pU+6DpuDfBP7S 9PGA==
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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden