|
|
Posted by robert on 04/28/06 22:14
"zacware" <zacware@comcast.net> wrote in message
news:1146245446.039378.247430@e56g2000cwe.googlegroups.com...
| I'm writing a product configuration system in PHP. I have a list rules
| to code, as if part A is added, then parts B and C need to be added as
| well. etc, etc.
|
| The rules change quite a bit as the products are refined, so I thought
| it would be really if I could give the product managers a little
| mini-language where they could build their own if-statements and other
| simple rules without having to come back to me to recode everything. I
| would write a DHTML interface that would be sort of a "script-builder"
| for them, and it would check for correct syntax before saving
|
| Has anyone ever seen anything like this done in PHP? I've started
| sketching out how I'm going to do it myself but it sure is a big task.
| I'd hate to be reinventing the wheel
|
| I figure I could let them enter raw php code and use the eval command
| on it, but that's somewhat dangerous! it would be safer to have a
| pseduo lanauge that would then be converted to php code in the
| background.
i've done this before w/ two approaches based on conditions.
first approach was applying regular expressions to a serialize string that
constitued a record or many records. this worked well between systems that
had to replicate the "rules" however, it was not very suitable for
end-users.
second approach was to simply define equality or non-equality...i.e. the
methods we evaluated were "=, !=, IN, NOT IN", etc.. the interface allowed
the selection of fields (w/ friendly pseudonyms), the selection of a value,
range of values, or list of values they could enter. then they'd specify the
equality they were wanting evaluated. as far as i was concerned, i simply
wanted a state of truth at the end of the evaluation. if the eval failed,
the record was considered valid...truth meant the condition matched a
non-violatable rule. in those cases, the description of the rule was
displayed.
the coding is quite simple, as such validations should be. both approaches
ported well between different languages and platforms.
while this was applied to record horizontal and vertical validation, it can
still be successfully employed to meet your needs.
i'd advise staying away from generating your own language just for this
purpose, lest you be consumed by building a very complex parser - which is
problematic and time consuming to say the least.
hth,
me
Navigation:
[Reply to this message]
|