Re: Proper control for a list of actions
Re: Proper control for a list of actions
- Subject: Re: Proper control for a list of actions
- From: Dave DeLong <email@hidden>
- Date: Wed, 10 Mar 2010 12:16:47 -0700
OK, following up:
I've spent a couple days playing with NSRuleEditor, and I've found some stuff out:
It appears to only be useful for a static tree of information (unless I dynamically modify the tree as rows are added and removed). I've come to this conclusion based on my tests, due primarily to this observation:
I created a node-style class to represent the possible *options* of the editor (not the final tree). One of these options presented an NSTokenField. I found that if I added a row to the rule editor that displays the tokenfield, and then add a second row (also with a tokenfield), the tokenfield from the first row disappears and jumps to the second row.
I understand why this is happening: the rule editor was using the same node object for both rows, which isn't how NSPredicateEditor behaves. NSPredicateEditor uses row templates, and then duplicates the template it needs for a particular row. I'm looking for the same sort of behavior, except I don't want it for predicates.
I suppose I could create a whole bunch of NSPredicateEditorRowTemplate subclasses for each possible action (which is fine with me) and use a predicate editor, but how could I get around the (apparent) NSExpression dependency? Some of my actions are just single items (like "Stop evaluating rules"), that don't have a left or right expression. Some may have more than one expression (like an "Other..." option that when selected, displays a textfield).
And suggestions on how to proceed?
Thanks,
Dave
On Mar 8, 2010, at 12:12 PM, Dave DeLong wrote:
> Hi everyone,
>
> I'm recreating a rules interface (ie, under these conditions, perform those actions). I have an NSPredicateEditor in place for the conditions portion, and it's working great. However, I'm wondering what would be most appropriate to use for the actions area.
>
> My initial reaction would be "NSRuleEditor", except I'm not sure how I'd integrate it. The documentation for NSRuleEditor is full of stuff about criteria and whatnot, and I'm not really sure how that applies. If I could get it to work, I think NSRuleEditor would be the best option because of the visual consistency between it and the predicate editor.
>
> My next reaction would be to use an NSPredicateEditor, but disallow compound predicates (except for the initial "AND"). I'm familiar with NSPredicateEditor, so this (I think) would be the "easiest" option. It also (obviously) has the advantage of visual consistency with the other predicate editor.
>
> I then thought I could build one using an NSTableView, but that seems overly complex and overkill, and it wouldn't necessarily be visually consistent with the predicate editor (without some serious graphics work).
>
> So: Is NSRuleEditor the thing to use? If so, how?
>
> Thanks,
>
> Dave
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden