What Brian said...
If I turned my decorator into a standalone bean, I could still run
configure() during (or after) init(), inject my generic validator and carry
on. As log as my new bean implements getRules() and validate(), I'd be
fine.
I would have a problem with my, ahem, wanton use of getTransfer(). In the
interest of having a single method to manage all validation rules, I have
two other methods that are invoked within validate(). emailIsUnique() and
usernameIsUnique(). Both run a TQL query to ensure that no other record is
returned with the same email (or username), where id != getId().
But I digress...
Paul
On Jan 11, 2008 11:30 AM, Brian Kotek <[EMAIL PROTECTED]> wrote:
> 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
> > >
> > >
> > >
> >
> >
> >
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
