On Feb 27, 2013, at 9:55 PM, David LeBer <[email protected]> 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 protected]> 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 protected]> 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 protected]> >>> 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 protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com >>>> >>>> This email sent to [email protected] >>> >> >> >> ————————————————————————————— >> 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 protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/dleber_wodev%40codeferous.com >> >> This email sent to [email protected] > > > ————————————————————————————— 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 protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
