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/archive%40mail-archive.com This email sent to [email protected]
