Hi
Seth,
That
is exactly it. If I have a RULE for selecting a TEMPLATE that may need
information about the USER, PAGE and possibly other things, we have a lot of
objects or candidate objects (in all caps) that could be responsible for
enforcing the rules.
When I
write it out this way, it seems to me that it is up to the template to know
which template to return, so I'd probably have a SelectTemplate() or
CallTemplate() method that would encapsulate the rules.
My
question is how does Template.SelectTemplate() KNOW the Session.User.Group or
Page.Name or the Request.IPAddress without breaking encapsulation?
The
best answer I have so far is as follows:
Have a
small set of global variables (via getter methods) exposed through a
GLOBALS object (better name anyone?) which has a request scope and acts as
an interface. Bad news is that I can't change that list of getters without
rewriting my code, but the base list is fixed anyway. I've been doing this 6
years and I CAN'T throw away basic concepts like user groups - old
apps logically depend upon them. The benefit of the interface is that
if I change where I store Session.User.Group or what I call it or how I store it
(data type), I only need to update my interface (the GLOBALS object) to get
all of the necessary properties and to transform them as required for backwards
compatibility, so request.GLOBALS would act as an internal API or list of
variables/getters that users could access.
Smells
anyone? Better ideas? Flames? (I'll take whatever I can
get!!!)
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Petry-Johnson
Sent: Thursday, January 19, 2006 3:31 PM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Generic Business Rules - Where?!Sorry if I'm being dense today, but I'm finding it difficult to create a mental model of the system you're describing. This is what I understand so far:1) You have a form that lets users create simple rules that act upon different variables that, I assume, are exposed by your framework or runtime environment.2) A publishing script parses those rules and creates CFML code that implements them. This CFML code is included during a visitor's page view to control what that visitor sees.3) As you move from CF 5 to MX you are looking to replace the procedural code generated in step 2 with something "more OO"; you want the generated code for your rules you use CFC method calls to implement the logic defined in step 1.4) You are struggling with the best way to expose the context of the visitor's session to the objects that enforce the rules.Am I getting closer?On 1/19/06, Peter Bell <[EMAIL PROTECTED]> wrote: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 submitMy 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 againIf 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-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Seth Petry-Johnson
Sent: Thursday, January 19, 2006 1:36 PM
To: CFCDev@cfczone.org
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: CFCDev@cfczone.org
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
cfcdev@cfczone.org 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/cfcdev@cfczone.org
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
