Re: Programatically Setting/Filtering D2W displayPropertyKeys
Re: Programatically Setting/Filtering D2W displayPropertyKeys
- Subject: Re: Programatically Setting/Filtering D2W displayPropertyKeys
- From: David LeBer <email@hidden>
- Date: Wed, 27 Feb 2013 08:55:45 -0500
Dave,
>> My #1 problem with D2W is that it's a bunch of non-compiler-checked strings.
I'm afraid that is the nature of D2W. If you cannot resign yourself to that, you may want to choose to forgo it's benefits.
In D2W the "correct" way to do things is usually via rules.
I could see creating an assignment object, but then you will still be left with needing to define a 'base' set of property keys and a set of keys to remove for each role. I'm not sure if that ends up benefiting much, at least not enough to justify not just doing it within the rules themselves.
D
On 2013-02-27, at 8:37 AM, David Avendasora <email@hidden> wrote:
> Hmmm. I see how this can possibly work, but I'd like to codify the logic that filters all possible keys instead of having to create new sets of keys for each possible "role" a user could have many roles.
>
> My #1 problem with D2W is that it's a bunch of non-compiler-checked strings. If an entity's properties change it will 1) not show up (best case) or B) throw a **runtime** exception (more likely). I HATE potential runtime exceptions even more than compound PKs.
>
> I'm looking for some way of WO look-for and execute a delegate method that filters the array of displayProprteyKeys returned by the rule system.
>
> Dave
>
> On Feb 27, 2013, at 1:26 PM, Jesse Tayler <email@hidden> wrote:
>
>> write rules using significant keys like
>>
>> session.user.role = "Admin"
>>
>> or
>>
>> session.user.access > 4
>>
>> etc.
>>
>> and you'll find D2W to be your greatest dream come true.
>>
>> write low-level rules, just a handful --- and you'll adhere to the logic of your business purpose.
>>
>> nice.
>>
>>
>>
>>
>> On Feb 27, 2013, at 12:10 AM, David Avendasora <email@hidden> wrote:
>>
>>> Hi all you D2W devs out there!
>>>
>>> Your worst nightmare is here, and I'm using D2W for a app about to go into production!
>>>
>>> After it's initial roll-out, one of the next features to be rolled out is to vary the attributes and relationships displayed to users based on permissions that they have.
>>>
>>> What I'd like to do is take the keys that are defined by displayPropertyKeys in the rule file and then filter it based on which ones they have permissions to.
>>>
>>> I have figured out a way to define and later recall which keys each users has permissions to view and/or edit, now I just need a mechanism to filter the rule-defined keys based on the currently-loggedin user's permissions.
>>>
>>> I've looked at a couple ways, but I'm not sure what is the best strategy. I'm thinking creating a custom D2W Assignment subclass is the way, but I'm not sure.
>>>
>>> Any suggestions?
>>>
>>> Thanks!
>>>
>>> Dave
>>>
>>>
>>> —————————————————————————————
>>> WebObjects - so easy that even Dave Avendasora can do it!™
>>> —————————————————————————————
>>> David Avendasora
>>> Senior Software Abuser
>>> Kaiten, Inc.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> —————————————————————————————
> WebObjects - so easy that even Dave Avendasora can do it!™
> —————————————————————————————
> David Avendasora
> Senior Software Abuser
> Kaiten, Inc.
>
>
>
>
> _______________________________________________
> 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