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 09:27:30 -0500
The problem is that there is not a fixed set of possible keys.
Available keys are defined by the components (both java AND wod) you are using, assignment objects, your model, and the kicker, keys you define in other rules. Therein lies the power and the beauty (and the danger and the dragons - the horrible brimstone belching, nightmare inducing dragons) that is D2W.
Is it foreseeable that you could write a validator that figured out how to find all of those? Yeah I guess so, but it would need to be undertaken by someone far more smartypants than me.
D
On 2013-02-27, at 9:13 AM, David Avendasora <email@hidden> wrote:
>
> On Feb 27, 2013, at 9:55 PM, David LeBer <email@hidden> wrote:
>
>> 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.
>
> Yeah, it's my #1 problem, but I'm able to live with that problem to a point as D2W has some really cool capabilities. I just wish the tools did some key validation or at least had some code-completion. I can't tell you how many times I've dug into the source code of RuleModeler only to walk away feeling like I could never hope to figure out how to add even the basics of either of those functions to it.
>
>> 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
>
> Yep, I figured one rule that defines all the possible keys that any user could see/edit/exicute
>
>> and a set of keys to remove for each role.
>
> Well, this one could be defined in code and at least use the EOGenerated Key static Strings so if a modeled property changes you get a compiler error. That's at least some protection.
>
>> I'm not sure if that ends up benefiting much, at least not enough to justify not just doing it within the rules themselves.
>
> Well, I guess it's a matter of degrees. I think there are times where what I'm talking about would certainly be just putting the same effort in a different place, but then I see lots of places where a little compiler back-watching would be priceless.
>
> Or maybe some sort of additional eclipse builder that validates the keys used in rules… some sort of rule-checking pony.
>
> That's the pony *I* want.
>
> Dave
>
>> 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
>>
>>
>>
>
>
> —————————————————————————————
> 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