NYCPHP Meetup

[Allen Shaw]

Kenneth Downs wrote:
>>Kenneth Downs wrote:
>>
>>>>One suggestion I would make is that each filter be given a name instead
>>>>of
>>>>an ID, and possibly let the user choose the name.  Then the filters
>>>>behave
>>>>like functions.  This makes nesting more intuitive.  So I can put two
>>>>filters into your table:
>>
>>This is not such a bad idea, but it requires me (or whatever admin) to
>>create the filters ahead of time and offer them to the user.  ...
> 
> 
> Not at all.  You can provide pre-defined filters if you like, or fall back
> to system-generated pseudo-names when the user is just typing in criteria.
> 
> To validate the criteria, you need a data dictionary.  To make the
> validation completely simple, you need to specify the criteria entirely in
> atomic values, and not allow parsable expressions.

Just as a follow-up: I think this discussion and the few days it's taken 
to transpire have led me to believe that, on the original question of 
data structure for nested filter criteria, my basic idea in the 
beginning was right: this is clearly a heirarchical relationship. But 
after digging more on the nested set model (reference recent thread 
"database performance"), I think I should be using that model rather 
than trying to tie records back to their parent nodes with a "parentID" 
column.  Thanks to Ken and others for ideas on the interface and 
management of those filters.

- Allen



-- 
Allen Shaw
Polymer (http://polymerdb.org)