Not
quite.
We
have a rules builder.
-
Users use a form which allows them to select from a list of globally available
request variables that clients have asked to base rules on in the past.
Examples would be user group (always set to "visitor" if user not
authenticated), page name, section name, time of day, day of week (different
website skin on the weekend anyone?!), etc.
-
They then select from a list of operators (equal to, less than,
longer than, etc.) and then either select from a pick list of statics or
variables or enter a custom static.
-
They then select the appropriate actions for both the evaluates
true and evaluates false tree (0..n actions each)
- They select the
parent rule (is it a top level rule or a child of the true or false paths of one
of the other rules)
- They set a
precedence (action order) for any sibling rules within the rules
hierarchy
- They hit submit
My script checks for a bunch of possible logical errors
(primarily based upon data type matching)
If the rule is invalid, I redisplay the form along with
any errors for them to try again
If it is valid, I save all of the little bits of data
to a couple of SQL tables (one for rules and another for
actions)
In CF 5, the user then calls a publisher script that
generates well formed CFML from the above data using nested cfif's and I include
it in the appropriate place (there is a template selector custom tag,
etc.).
The problem I have in MX is finding the best place to
save the logic to. As I think about it, latest thinking is as follows. Each rule
builder should be saved to the object the rules relate to (not which ones they
use data from). For instance, a template object will have a GetTemplate() method
which includes all of the appropriate logic and handles getting the right
template.
The only downside is that GetTemplate() may
need to know user group, page name, section name, URL, or a bunch of other
things from my "variables list". Do I (shudder) just define a formal interface
that always gets and displays those global variables like a GlobalVariables
struct or object with request scope? I suppose a slightly neater solution would
be at generation time to generate an array of all of the variables and
which objects they belong to that are currently within a given rule set. I could
then dynamically concatenate code to make the calling script pass those
variables or make the GetTemplate() call them using the appropriate getters. I
am not a big fan of getters as I like to keep my objects as shy as possible, but
I can't immediately see a better approach.
Input from anyone who has ever actually written an
object oriented site would be much appreciated!!!
Best Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Petry-Johnson
Sent: Thursday, January 19, 2006 1:36 PM
To: [email protected]
Subject: Re: [CFCDev] Generic Business Rules - Where?!Just to make sure I understand your situation:1) Users write out their page logic using a simplified sort of pseudo-code2) The pseudo-code is then submited to a parser or "compiler" which generates actual CFML3) That CFML is saved to a file which is then included during a page visitIs that correct? Are you looking to replace step 2 or step 3 (or both) with an OOP approach?
On 1/19/06, Peter Bell <[EMAIL PROTECTED]> wrote:End user uses a web based admin to generate business rules (Simple "if
variable operator variable/static then action else action endif" with
support for nesting and precedence). They also get a "rebuild" button which
takes the individual elements (variable, operator, action, etc.) and
concatenates well formed Cold Fusion which it then saved to a CFM that gets
included at design time. That was how the CF5 app worked. Now the string
would be saved as a method of a cfc (I'm writing my cfc generator as we
speak) so semi-technical end users can effectively change simple business
logic (if this user group show that template, etc.) without breaking the app
or affecting the runtime performance.
I'm fanatical about letting end users change just about anything. That way I
can charge them a monthly fee for the use of my software rather than having
to actually work for a living and manually make the changes they require :->
-----Original Message-----
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf
Of Phillip Senn
Sent: Thursday, January 19, 2006 9:14 AM
To: [email protected]
Subject: RE: [CFCDev] Generic Business Rules - Where?!
> implementing the rules was easy - I just needed a global list of
> variables
and to generate the logic at design time
Are you saying you have somehow opened up your program to the end user?
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
