Now rule driven Selenium testing... that would be cool. D
On 2013-02-27, at 9:27 AM, David LeBer <[email protected]> wrote: > 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 protected]> wrote: > >> >> 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/dleber_wodev%40codeferous.com > > This email sent to [email protected] _______________________________________________ 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]
