If the validation logic itself is in a separate component, how would you be
too dependent on Transfer? If you changed it and wrote your own bean, you'd
still just be injecting the validator for it to use. Am I missing something?
On Jan 11, 2008 2:23 PM, Bob Silverberg <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
