Form validation using CFCs

[mate of the state]

I have a pretty nice method for coding forms using server side validation. One
<label /><input /> pair might look like so:

<label for="foo">Foo!</label>
<input type="text" name="foo" id="foo" value="<CFif
isDefined('form.foo')>#form.foo#<CFelse>#query.foo #</CFif>" />

Now, this would be for something like an 'edit' form, where initially we'll
want to populate the field with the query value, but use the posted value if
they tried to submit the form but something was wrong. Once a form is posted,
I'll have the values run through an include called something like
validate-forms.cfc. This will contain a switch that checks the value of
#form.toValidate# which would have been supplied as a hidden field of the form.
Within' each case is a series of checks for empty values, invalid (against
regex) values and so forth. When errors are found, I save them in a struct
called something like #errors#. Then, if there are any problems with the form,
I can notify for each field like so:

<label for="foo">Foo!</label>
<input
type="text"
name="foo"
id="foo"
value="<CFif isDefined('form.foo')>#form.foo#<CFelse>#query.foo #</CFif>"
<CFif structKeyExists(errors,'foo')> class="empty" title="#errors.foo#"</CFif>
/>

Now, recently I've been moving over to stronger use of CFCs and other levels
of seperation and abstraction with CF. I'd like to use a CFC to process the
form and validate it, for instance, but I don't understand how I'd accomodate
the rest of what I have going on here. Once values are passed to a CFC, if
there are errors, how can I return the user to the view page while retaining
knowledge of the posted values as well as the errors created?

[travelinrob]

The same way your view page is seeing the 'errors' struct now. You can create the struct by CFC function calls and/or return a struct from a function call.

[mate of the state]

One of us is not understanding something... I'll just explain more what I see
as the problem I don't know how to get around, and maybe you or somebody else
can clarify things further:

User fills out a form. The form posts to a CFC. The CFC validates the form,
creating a struct called #errors# if any are found. Now, once that's done, the
CFC will want to direct the user to the appropriate view page using
<CFlocation>. Once they are at the new page, how can I still have knowledge of
those posted #form# variables as well as the #errors# struct? The only way I
understand how to pass along data using <CFlocation> is via the query string,
or perhaps a persistent scope like session. Neither of those seems appropriate
here, though.

[travelinrob]

I wouldn't post to a CFC. I would post to a process page that creates an
instance of the CFC and calls it's functions. In the process page you can then
include, upon successful checking, the page with your forms. The forms page
will then see the structure(s).

[mate of the state]

Okay, but then it seems like we're not far from the self-posting forms approach
I'm exploring getting away from. With your example, why would I want to do that
rather than the same thing, but all within' the same template?

[travelinrob]

CFCs can be used for generic code that can be used across multiple templates.
For instance, you wanted to check for nulls or other reg expressions. That is
something you will do with many templates. Each of those templates can make an
instance of your validate CFC and call the functions that are appropriate to
each. Then, you don't have to write your validate code multiple times. Or, you
might make a CFC to contain a group of functions for a particular project. All
the functions (components) of that application can reside in one CFC, or
multiple, if that makes sense. It doesn't make sense to put everything in a
CFC. But a page of commented function calls is much cleaner than a page of code
everywhere.

[mate of the state]

I understand and am with you on all that, though I think you have given me
insight into a better way to structure my validation CFC(s), so thanks for
that. :)

Could you elaborate on self-posting vs. not, though? As I said, I think I can
understand seperating into a processing template for organization's sake, but I
guess I got the impression there was more to it. I've read that self-posting is
bad form (ha) and should be deprecated. But with the functionality you discuss,
I wonder why I shouldn't just post back to the same template. Any thoughts on
this?

[travelinrob]

I have not read anything on the self-posting debate. I would need to do some research and interpret both sides before I could answer that for you. I still self-post.

[travelinrob]

To be clear, in self-posting I mean the I have a main index that includes
templates based on both url and form parameters. But, mostly all through one
page except for pop ups and unrelated by-products.

[mate of the state]

That's fine. I think most of the reasons for getting away from it have to do
with going towards smarter levels of abstraction and seperation, but a lof of
the solutions there have to do more with processing and abstract ways of
thinking about your code. Physical organization is a pretty open ended,
personal topic, I suppose.

To be clear, this is what I'm thinking when I think of a self-posting form. I
will usually have an action template for an object, let's say, a product.
Within that, there'd be an option switch, of which one case would be "update."
The update case handles both new inserts and updates to existing records.
Something like...

<CFquery name="foo" datasource="#request.dsn#">SELECT * FROM foos WHERE id =
<CFif isDefined('url.id')>#url.id#<CFelse>-1</CFif>

<CFif isDefined('form.toValidate') and form.toValidate is 'fooform'>

<!--- process posted data --->

<CFelse>

<!--- form not posted, show form --->

</CFif>

[travelinrob]

I have similar code, except I have includes below your comments. I keep all of my sub-templates in a tpl directory.