Sounds very similar to what I'm doing, except that I don't define the rules
inside the decorator (I'm using Transfer as well). I had originally thought
of doing that, but I didn't want to tie myself to Transfer as an ORM, so I
thought it best to keep that stuff out of the decorator.
This is actually something I have often struggled with. I love having the
Transfer decorator, but then I'm concerned about putting too much in there
as suddenly the business logic of my app is tied to Transfer. So instead
I'm injecting components into the decorator.
Any thoughts on that issue?
On Jan 11, 2008 1:45 PM, Paul Marcotte <[EMAIL PROTECTED]> wrote:
> I have a system that is similar to Bob's. My "validations" are basically
> a collection of metadata that describe the rules a given property must
> meet. I'm using transfer, so at present I store set the metadata rules in
> the configure() method. This is a simple struct with named atttributes.
> Here's a sample.
>
> variables.rules["Username"] = StructNew();
> variables.rules["Username"]["label"] = "Username";
> variables.rules["Username"]["datatype"] = "string";
> variables.rules["Username"]["required"] = true;
> variables.rules["Username"]["min"] = 6;
> variables.rules["Username"]["max"] = 16;
>
> I'm still trying to decide whether to store all object metadata in a
> global store (and whether the object needs to know this information). I'm
> architecture challenged, so suggestions are welcome.
>
> In addition I have a context collection that lists the set of properties
> that need validation in a specific context.
>
> variables.context["register"] =
> "FirstName,LastName,Email,Username,Password,ConfirmPassword";
> variables.context["login"] = "Username,Password";
>
> On the server side, I inject a generic validator that contains a
> validate() method that accepts two arguments. An object and a context.
>
> My transfer objects delegate validation to the validator like so
> (pseudo-code)
>
> validate(context) {
> return validator.validate(this,arguments.context)
> }
>
> transfer object also have a getRules() method that returns the set of
> rules to validate against. So inside the validate method, the validator
> gets the rules from the object it is validating.
>
> The validator loops over the collection and return a structure of errors.
> An empty struct means no errors.
>
> On the client side, I wrote a jQuery plugin that adds validation to a form
> by accepting the set of rules (by context) encoded as JSON.
>
> The plugin is a generic validation routine that which (like the generic
> validate method) "knows" the DSL that I've defined in my metadata. So, if I
> decide that I want to add "customtype" on top of "datatype", as a rule, I'll
> only have to modify the validator and the plugin.
>
> The plugin attaches both blur and submit validation to a form. So for a
> login form, I have a script tag like so:
>
> <cfoutput>
> <script type="text/javascript">
> var rules = #json.encode(rules)#
> jQuery(function() {
> jQuery("##user_login").bluerules(rules);
> });
> </script>
> </cfoutptu>
>
> In this example user_login is the id of the form. If anyone is wondering
> about the named attributes for structs and JSON encoding, I chose the route
> because Javascript is case sensitive whereas CF is not. I didn't want to
> blast everything down to a lowest common case. ;)
>
> I called the plugin "bluerules" since I'm working with Blueprint CSS at
> present and wanted to leverage the form and button styles.
>
> Like Bob's solution you only define the rules once and get server and
> client validation. So, if js is turned off it degrade well.
>
> I know it needs a bit of work, but I'm pretty happy with the result at
> this point.
>
> I've been harassing a couple of folks regarding architecture decisions
> (you know who you are) to improve things. Separation of concerns isn't my
> strong suit. :(
>
> If anyone wants a live demo, ping me off list. I'm not ready to unveil
> the project that gave birth to this implementation.
>
> Cheers,
>
> Paul
>
>
>
> On Jan 11, 2008 7:07 AM, Bob Silverberg < [EMAIL PROTECTED]> wrote:
>
> > Let me clarify that last bit - the JS validations are not present in any
> > of my HTML templates, but the view does ask for the JS validations at the
> > end of the request, after all of the HTML has been generated.
> >
> > Bob
> >
> >
> >
> > On Jan 11, 2008 10:05 AM, Bob Silverberg <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Because the validation rules are separated from the implementation, I
> > > can easily switch implementations. I have a JavaScript renderer that
> > > takes
> > > the validation rules and generates the JS, so I can replace that if I want
> > > to change implementations. This scheme also means that the JS validations
> > > are not present in any of my view code.
> > >
> > > Bob
> > >
> > >
> > >
> > > On Jan 11, 2008 10:00 AM, Brian Kotek <[EMAIL PROTECTED] > wrote:
> > >
> > > > Does this handle varying JavaScript validation implementations, are
> > > > are you basically committed to using one in particular?
> > > >
> > > >
> > > > On Jan 11, 2008 9:12 AM, Bob Silverberg < [EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > Here's a high-level summary of what I do:
> > > > >
> > > > > 1. I define all of my validation rules in the model, so they are
> > > > > defined in one place only. E.g., the User model contains the
> > > > > validation rules for Users.
> > > > > 2. When I need to generate validations I ask the model for the
> > > > > validations, which in my implementation are returned in an array.
> > > > > 3. When I need to process validations, I just loop through the
> > > > > array and generate a validation for each validation rule. I can do
> > > > > this as
> > > > > part of my Update routine for server side validations and I use these
> > > > > to
> > > > > generate my Javascript validations in my view code just before
> > > > > rendering the
> > > > > page.
> > > > >
> > > > > So, I have all of the validation rules specified in one location
> > > > > only (the model), when I need them (either to render a screen or to
> > > > > do an
> > > > > update) I just ask the model for them, and I have two versions of
> > > > > code that
> > > > > can use those validations rules to implement actual validations (one
> > > > > for
> > > > > server side and one for Javascript).
> > > > >
> > > > > HTH,
> > > > > Bob
> > > > >
> > > > >
> > > > >
> > > > > On Jan 11, 2008 4:46 AM, Alan Livie < [EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > I still haven't come up with a solution for this.
> > > > > >
> > > > > > I am working on a project removing duplicated code, creating a
> > > > > > basic
> > > > > > domain model from a procedural app but one place where business
> > > > > > rules
> > > > > > are being duplicated is in the js validation files that check
> > > > > > forms on
> > > > > > the site.
> > > > > >
> > > > > > I could generate the js from the CFC's that handle the business
> > > > > > rules
> > > > > > but not sure the best way to go about this.
> > > > > >
> > > > > > I could also use AJAX to do the validation server-side but I'm
> > > > > > also
> > > > > > uncomfortable having the server do extra work when it doesn't
> > > > > > need to
> > > > > > (and be slightly slower than client-side js)
> > > > > >
> > > > > > Someone mentioned on this group that Brian Kotek tacked this
> > > > > > problem
> > > > > > using the Bridge Pattern.
> > > > > > Brian, if you read this can you give more details on this. I'd
> > > > > > be
> > > > > > interested if you have worked on this problem.
> > > > > >
> > > > > > Anyone else with ideas?
> > > > > >
> > > > > > Alan
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>
>
> --
> Paul Marcotte
> Fancy Bread - in the heart or in the head?
> http://www.fancybread.com
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
