Smarty Forum Index Smarty
The discussions here are for Smarty, a template engine for the PHP programming language.

SmartyValidate: a simple yet powerful form validation plugin
Goto page Previous  1, 2, 3 ... 10, 11, 12 ... 16, 17, 18  Next
 
Post new topic   Reply to topic    Smarty Forum Index -> Add-ons
View previous topic :: View next topic  
Author Message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA

PostPosted: Mon Jul 26, 2004 4:46 am    Post subject: Reply with quote

webadept wrote:
Let's face it, I can write the validation of a form in a lot less code, much less over head and, .. less time, than it takes to use the Validator... any validator. The purpose of a validator, again, in my little world, is the designer and the maintainers of the form, and the site when i'm gone. If I wrte the validations, then they are in the PHP, and as you say, I can do a heck of a lot more than what might be possible in the template areas, but .. it requires changing PHP to alter or maintain it later.


Thanks for your input, this is the stuff I'm looking for. There certainly seems to be two sides of the camp. One side adheres to general template guidelines, eg. keep validation rules PHP side and presentation template side. OTOH, the ability to maintain a form and its validation all in one place (the template) certainly has its convenience factor.

If validation rules are moved to PHP side, what purpose is a validator now serving? It still abstracts criteria and transform functions to plugins, but now form validation requires PHP and template modifications to maintain it, as you pointed out.

Maybe if PHP side validation is added, BC should be maintained so it can be done either way.
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Mon Jul 26, 2004 6:58 am    Post subject: Reply with quote

mohrt wrote:
OTOH, the ability to maintain a form and its validation all in one place (the template) certainly has its convenience factor.

Of course, it suddenly becomes less convenient when multiple templates share criteria and you have to duplicate template (read: validation) code in many places. In many ways, this is the same argument that justifies abstracting the HTML out of the PHP code as a template.

mohrt wrote:
If validation rules are moved to PHP side, what purpose is a validator now serving? It still abstracts criteria and transform functions to plugins, but now form validation requires PHP and template modifications to maintain it, as you pointed out.

Well, this is already the general case for a system like Smarty. Adding a new field typically will require a php and a template change. In other words, data is pushed from the PHP, not pulled by the template.

The question I see, is who is responsible for the data? The PHP coder or the template coder? Do template coders really design/implement form criteria? One of the things that is so great about Smarty is that it helps draw the line between the coding team and the design team. The right tool for the right job also means the right person for the right task. [Another thing, I find that whereas coders typically want to get things "right", designers typically want to make things "work". When we are talking validation, this is an important distinction.]

Not-withstanding my comments, I can see this implemented in-template as a separate layer instead of intermixed with the display template. The idea is that you encapsulate all of the criteria specs/rules in a single template which does nothing else. A display template would pass the template to a special plugin that would load it into the display's context. Compare to config files which are also abstracted out of templates.

Of course, this all begs the question: are we (or some of us) really after a more robust language/system to deal with the data in its own layer? I'd feel better about a mechanism that provided a consistent way to define data interfaces but I suppose that for some classes of problems that that amounts to over engineering.


Last edited by boots on Mon Jul 26, 2004 4:10 pm; edited 1 time in total
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA

PostPosted: Mon Jul 26, 2004 4:04 pm    Post subject: Reply with quote

Now we're getting somewhere Wink so a way to define form validation criteria with a separate abstraction layer (eg. not in the PHP code, not in the template display.)

How about this:

index.php
Code:
$SmartyValidate::form_load('foobar.form');
$smarty->display('form.tpl');


form.tpl
Code:

{if $validate.foobar.is_error} there were errors... {/if}
{validate field="name" message="name cannot be empty"}
<form ...>
...
</form>


The form definition files could be kept in the config directory with the ".form" extention to keep them separate. The format of them would need to be determined (XML tags, etc.)

Any comments on the whole approach?
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Mon Jul 26, 2004 4:18 pm    Post subject: Reply with quote

The only comment that springs to mind is that SmartyValidate::form_load() should have a template plugin analogue just as config_load does. This way those who prefer to handle the details from PHP can and those who don't mind extra binding on their templates can load it directly from the template. I think you know I don't favour the latter approach, but I suspect that a few people here probably would Wink
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA

PostPosted: Mon Jul 26, 2004 4:46 pm    Post subject: Reply with quote

Yeah I had {form_load ...} in my first draft, but changed it to SmartyValidate::form_load() on second thought since this makes better sense, but both could be accomodated.
Back to top
View user's profile Send private message Visit poster's website
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA

PostPosted: Mon Jul 26, 2004 5:00 pm    Post subject: Reply with quote

Cocoon forms have a very similar approach.

http://cocoon.apache.org/2.1/userdocs/forms/
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Mon Jul 26, 2004 5:09 pm    Post subject: Reply with quote

I had been giving some glancing looks at XForms recently and again, there is a layered model approach there as well. I think this is the right nail to hit. The question is, how much of the hammer do we invent and how much do we borrow from another toolbox?
Back to top
View user's profile Send private message
webadept
Smarty Regular


Joined: 09 Mar 2004
Posts: 41

PostPosted: Tue Jul 27, 2004 1:31 am    Post subject: Reply with quote

Man, when you two get moving you are frightening. Smile Amazing, but frightening Razz

Anyway, again with my two cents (just got paid so i can afford it)

You have, at this point with no further code, these things,
Basic validation, which is understandable and even the two aritists I've taught it too already picked it up in less than an hour.

Basic transforms, which work very well

A clear method of adding in custom transforms and validations, which I"ve found useful already .. made a validation called 'isCurrentPassword' which came in handy in a password change form. Very slick.

What more do you need for 'Validation?' ... I might be missing the point of the last posts between you two, but .. aren't we now talking about 'Form Creation' and not Form Validation' . i'm all for form creation. I began working on an abstraction layer for Smarty back in Feb, where the fields were defined in a config file, and forms created via Object model. It was cool, and fun to work on ... a little mental exercise while waiting for the next gig to come in.
Code:

[customer]
linegroupings = date_inserted|firstname,lastname|company|.....blah blah
formtitle = New Account Registration
submit = Register
cancel = Cancel
help    = helpregister.tpl
divname = customerDiv
date_inserted = startdate|hidden,value=KEY_date_select?today|0|0|0|0|0|0|0
firstname = First Name|text,size=30,maxlength=35|isRequired,isText|onFocus="highlightrow(this);" onBlur="resetBg(this);" 
lastname = Last Name|text,size=30,maxlength=35|isRequired,isText|onFocus="highlightrow(this);" onBlur="resetBg(this);"
company = Company Name|text,size=30,maxlength=50||onFocus="highlightrow(this);" onBlur="resetBg(this);"

....
blah blah blah..


Two things came to mind while working on this, the first was, .. it was not the easiest to teach the basic artist, and two, making out the config files was more work, and more typing, than just making the HTML, .. so, where was I saving time? What was I realy creating?

But I do think, from what I understand from your recent posts that you are now talking about another tool, not the same one.

The programmer controls the data, that's a given. The customer says what they want, the programmer decides how they get it. The designer can not be in control of the data, as in the database. That isn't happening.

Niehter the programmer nor the designer are in control of validation rules used on the site. The customer is in control of that. And the customer is guided by the users/visitors of the site. Every form I've made (well, let's say 80% of them) has required a change in validation at some point, because the rules sets at first design were either too strengent or too laxed. New fields are sometimes required, but that is not what we are talking about here, we are talking about validation. Redesign, and new fields is .... again a given, call the programmer.

Sometimes it is just precieved that a new field is needed ,the html_select_date is a perfect example of this. Start with one field but now you want three.. the data doesn't change, just the form. First Name Last Name could produce the same effect and be handled in the same fashion.

Just from your writings so far I know you would probably create a better form creator than mine started out to be. I haven't seen one yet that I thought was 'useful' in a production level sense of the world. Assome in consturction and forthoght.. yes, amazing in creation, definitly, usful for my day to day programming.. unlikely. ... simply because creating a form isn't that difficult. Getting a new form creator, is ... getting something that you have to learn how to use, to create what you know how to create already and adding a level of possible errors and bugs to a system that doesn't have any.

Also, the form fields are set by the programer, so, the programmer (at least this little programmer) doesn't want to type anymore than he has too. Or add levels of possible errors to a stable system. ... Which is why I abandoned my project in April. I couldn't think of a faster way of typing in
Code:

<span id=fnamf ><input name=fname value="" class="formfield"></span>


just couldn't do it.

Validation is a whole different thing however, and you have nailed it hard.

webadept --out
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Jul 27, 2004 2:34 am    Post subject: Reply with quote

There are some rather interesting points that webadept makes. I'll just make one comment for now regarding form creation.

The act of creating a form as webadept presents it seems to be consistent with creating a display interface; but the UI is only one aspect of forms. Handling and processing forms is another and at least as important. Yet putting all of the semantics involved in the form into the display portion effectively "hard-codes" the form model thereby making it opaque to other portions of the application. For example, the script that needs to deal with posted data from the UI must implement its own model of the form. The irony is that the base data that the form is intended to present in the UI arrives from the calling script to begin with. There is a disconnect between these two views of the "form". A uniform mechanism that abstracts form details provides the opportunity for a unified model that is applicable (and can be consumed) in different contexts.

I don't think it is an understatement to suggest that writing form processing is both monotonous and error prone. At the same time, it is vitally important that the application do this task well and that it does it correctly. An easy-to-use abstracted model and controller would certainly be useful to programmers for certain applications. Of course, if it leads to a more complicated process for designers then that is not a good thing as webadept pointed out. I suspect that there is a happy medium as long as we remember that we don't want to change the way that the designer works--just keep passing data arrays via Smarty as always so that the designer can stick to familiar and tried concepts. However, how the data is passed and how it is accessed is another issue.

Here's one idea: in addition to passing a .form to form_load, an array of data needs also be passed. The result is a structured array of the validated data (it could be populated as $smarty.form.<name> or similar). Similarly for {form_load} except that the source data is obviously passed from the template and can thus be a subset of the data originally assigned to Smarty.

At anyrate, I think it is dangerous to think too big for this one--a completely generalized data abstraction model is not trivial. I also agree that for this type of tool it is easy to do a lot of things right and yet still get it wrong overall. That's why I think it is our good luck that Monte is driving this since he seems to have a really great sense of what works and what won't. I also think it is a problem that is ripe for a simple but effective solution. Hopefully we can find one that is generally useful.
Back to top
View user's profile Send private message
webadept
Smarty Regular


Joined: 09 Mar 2004
Posts: 41

PostPosted: Tue Jul 27, 2004 9:28 am    Post subject: Reply with quote

I seem to be sticking my feet in a little here and since I've come this far, I might as well go for a swim eh?

These are just my thoughts and certainly (more than likely) not the general view of things or even close, but, this is the way I think about data, code and presentation. And the reason Smarty attracted me so strongly was it appeared to follow along this point of view, however warped my understanding of it might be.

Data is data. It is independent of process, function or presentation. A form is also not, in and of its self dependent on, or requiring data or code processing, nor is it, in and of itself, reliant on it. A perfect example of this is a form whose gathered data is sent via email, or jabber, or socket. These forms do not require, nor even desire the processing of the back programming. Or even validation

A coder's view of Valid data, is not a designer's vew or a clent's view of valid data. A coder wants to make sure the data 'fits' in his/her database, that it is not an attempt to hack the system, that it is a number if the field takes number, and a letter if the field takes letter. That the date is indeed a real date, and not somthing else.

A designer, or client (as i said before I believe the client is the real driver of form validation) want basically the same thing, but for much different reasons. They don't want just a number in the number field, they want a SS, Phone or Credit Card number in there. 2004-07-27 is a valid date to a coder, but not to a client or designer looking for a birthdate on a purchase form.

Something valid to their needs, and "valid to their needs" is a dynamic value, whereas the "valid to the coder' is not, it remains constant, and more or less unchanging. Put it this way, the only reason I'll think of 2004-07-27 as not being a vaild date, is if someone tells me it is not, and that someone is either the designer, or the client, or, I'm not listening to them.

When theytell me this, and only at that time, with your Validation set here(not my internal checks for getting data into my database) I will create function_over18() Why? because the form told me too, and if one form says it, there will probably be others, so I will create this funciton, this validation, so that it can be used on other forms.

Which other forms and which field those other forms are going to use it on, I haven't a clue, and I don't care. In fact, I may decide that what I really need here is not a form vaildation at all, but a plugin function that allows the choice of years_before such as {years_before years=NN} which will asign a variable a date, which can be used in with the onOrBefore vaildation already in place.

The reason I might decide this is it lets me care even less what the validation rules are for a date field, as required by the designer or client. isDate is enough for me. That's all I care about .. isDate. becaue my field is a date field and my errors will be caused by non date entry.

It will never cross my mind to change the PHP of the main program procesing the website as a whole in situations like this. Never. This situation is only a 'design' need, and that need is going to change. Changing my main code for such requests is ludicris. I believe the term that describes what such actions create is 'spagehtti" code.

We move this site up in time and suddenly the age required is 21. The coder is uneffected. Only the owner is effected by this, and needs to alter his form validation. The isDate is still a required, and functional aspect of the programming, it hasn't changed.

Another year goes by, and a new form is needed, however this form's data is to be emailed, not processed to the data base. It does however require validation (as seen by the designer/client)) on the fields. This form, with your sysetm, as designed to this point, gives them all the tools they need. In my most recent project they need only write this at a command line

cat blankformpage.php > contactemail.php
cd templates
cat blankformtemplate.tpl > contactemail.tpl

And put in their form. Everything else is done. Again, the coder is happly chewing on crunchy stuff and need never look up from his own world.

A form is created by the data it is given from the programing, but the programming was created to appease the form and allow its creation. The form existed first. In thought and idea only perhaps, but it was there, and my paycheck depended on my writing of code which allowed that form to exist. Any other code would not be paid for.

Symantics? you betcha. But what is true programming without clear thought on what is what and who is who?

We write interface driven code. without interface, the code is meaningless. What came first, the form or the data? the Form, every time, and the form was the requirement of the client or the designer, to which the coder supported. Not the other way around If a coder needs data, she doesn't create a form, she creates a function which gathers that data. Interface is for the meat. (unless we're talking playstation games here and that's all different.)

It is however an interesting area of thought. One that I've ping-ponged back and forth over for several years now. I'm enough of an old-school coder to think that the creation of forms, those things in which data is placed in and processed back to a database to drive other parts of the site, should not be something that is dynamically created. Real thought should go into them and real time.

But.. i'm also enough of a creative mind to want to see it done, and far too lazy to not want to write it so that I don't have to HTML out yet another f'en form.

As it stands in my own mind right now however, I really wanted and need the tool you have here. So if you decide that it should alter and change to a more internal method, which hampers what I see the usfullness of it being, then I will maintain and keep this started path that you have created. (as opensource and same licence and all of that happy stuff. ) Its that important to me.

Yes, it is simple, and yes it is narrow, which is exactly what I look for in a tool. Well done indeed, I say. Ive gone over some of the requests, such as AND OR statements, and see those as something lacking in the code before the data reached the validation point. In other words, it should have been done already or, should be done outside validation.

Validation, by definition is the checking to verify the existance of a predetermined set of values, not a tool altering the website so that it is valid according to radom valuations of data put in a form. This is not to say that this thought or need is not vaild, just that it is another tool which allows that to happen. Good tools are simple ones, good functions are short ones. Good clients are paying ones.

Okay, I've spewed far more that I thought I would.. time to get out of the pool, and stop the madness from spreading further.

webadept --out
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA

PostPosted: Tue Jul 27, 2004 2:48 pm    Post subject: Reply with quote

At this point in time, this is my general consensus.

When I first started building SmartyValidate, one of my goals was to alleviate the complexity of form validation in the PHP code. It seemed to me that there was a lot of repetitive and tedious work done on every validated form, and I wanted to create a way to abstract this to a validation process. WIth that in mind, the PHP code would be kept to the following basics:

    * initialize a form for validation
    * collect posted form data
    * test that it passes validation criteria
    * if fail, assign posted vars and redraw form
    * if pass, continue to next process


We have that covered (what it does now.) What was left over were two items: validation criteria and error message display. Ideally, the template should be concerned only with the following basics:

    * was there an error on the form?
    * if so, what was the nature of the error?
    * create an error message and display it.


OK, so that takes care of the error message display. But what about the validation criteria? We don't want this in the PHP code for reasons already mentioned above. This ended up going right into the template since that seemed to be the remaining logical choice, and pretty harmless for most intents and purposes. The problem with this approach is that now the validation criteria is dependant on template syntax, and the more complex this gets, the more information is presented in the form that the designer really doesn't care to know about.

The next logical step (IMHO) to fix this problem is to move the validation criteria itself into a form definition file (so-to-speak). This alleviates all of the problems from what I can see. The template is now soley concerned with error message display, and our form validation criteria can now easily accomodate a more complex feature set without the constraints of the template syntax. This doesn't really add any complication to form management either, you are just editing a separate file for the criteria instead of at the top of the form template (the presentation layer!)

So, here is a preliminary design approach:

index.php
Code:
SmartyValidate::connect($smarty);
SmartyValidate::register_form('foobar','foobar.form.xml');
// rest of validation tests, assigns and processes


When we register the form, we are setting the form definition file name (probably located in the config_dir.) This seems to be a good mechanism instead of a form_load() function, since every form you register would need a corresponding criteria file. (I haven't quite determined how to handle the 'default' form yet, maybe anticipate a 'default.form.xml' file?)

Now, in the template, we would have the familiar display logic, but no criteria definitions:

foobar_form.tpl
Code:
{if $validate.foobar.is_error}<div class="error">There were errors on your form.</div>{/if}
{validate name="password_is_empty"}Password cannot be empty{/validate}
{validate name="password_not_match"}Your passwords do not match.{/validate}


Notice there is no validation criteria present, only name placeholders to inform the template designer what the nature of the error message is. There would still be halt and assign parameters allowed, useful for presentation. I also made the validate tags into block functions for more error message formatting flexability.

Now comes the criteria definition file. I think a straight forward XML format would be the best approach, this would be easy to read and understand, easy to parse by PHP and flexible enough to cover any features we would require. I have no idea what the schema needs to be, but here is a conceptual example:

foobar.form.xml
Code:
<form name="foobar">
   <field name="username">
       <tag name="username_is_empty">
          <criteria name="isNotEmpty" />
          <transform name="trim" />
       </tag>
   </field>
   <field name="password">
       <tag name="password_is_empty">
          <criteria name="isNotEmpty" />
          <transform name="trim" />
       </tag>
       <tag name="password_not_match">
          <criteria name="isEqual" field2="password2" />
       </tag>
   </field>
</form>



With this format we can pretty easily come up with ways to handle AND/OR logic, create complex dependencies on other fields, etc. We have not given up our simplicity in the PHP code, and we have not made the templates any more convoluted than they need to be for presentation.

Thoughts?
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Jul 27, 2004 4:13 pm    Post subject: Reply with quote

@Webadept, I think we are getting off-topic but I felt the need to reply, at least in part. Sorry, but no designer should be implementing the rule that the minimum age is 18 or 21 or whatever. Defining the age limit (or any criteria) is not a presentation issue, period. I realize you see that differently but from where I am sitting (behind a corporate firewall) template designers do not maintain the application or its functioning or its definition. They maintain the look and feel and that is all.

To be honest, coders who disappear on their clients saying things like, "here, just modify this template file" kind of scare me (not that that is you, but you see what I am getting at, I hope). I see a web application as a technical endeaver that requires technical people making technical decisions. I'm not trying to under-estimate the competence of designers (or even individuals) but rather looking at the various tasks involved and where they ought be addressed. Setting the criteria for a field in-template is simply wrong. That it makes it easier for a designer to manage is irrelevant since it is not the designer's role to manage that issue--the place to implement that decision is not in the display. The only part of the application that should be in the template is the presentation semantics and layout.

Greetings.


Last edited by boots on Tue Jul 27, 2004 4:26 pm; edited 1 time in total
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Jul 27, 2004 4:25 pm    Post subject: Reply with quote

@monte: looking good. A couple of comments:

Form Definition
------------------
XML is fine, though it increases requirements on the PHP side. Under PHP5, this is actually very convenient. Under PHP4 it is far less convenient. I'm also a big fan of YAML.

I had earlier suggested a specialized template layer for this since it provides a compiling service by default and since the existing work already done could be likely be leveraged.

At any rate, if an alternate file format is used, I think it should have the features of being easy to write, easy to parse and importantly, should be compiling.

Data Passing
---------------
I suggested passing the data to SmartyValidate along with the form to produce a payload of scrubbed data to be used in the template because I figured it made sense in several ways.

For one, form data handling can be generalized to some extent.

For another, if we honour cache_id and compile_id's, we can serialize data and leverage Smarty's caching features for the data itself while harmonizing this process with the display's use of those variables.

I won't try to carry the torch on these last points, though. I expect that the audience for them is small.
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA

PostPosted: Tue Jul 27, 2004 4:40 pm    Post subject: Reply with quote

AFAIK, PHP comes with XML parsing functions enabled by default. I'm not sure how far back that goes, but probably enough to rely on? As for compiling, It would be fairly trivial to convert the XML file into an associative array that could be written to a compiled file.
Back to top
View user's profile Send private message Visit poster's website
webadept
Smarty Regular


Joined: 09 Mar 2004
Posts: 41

PostPosted: Tue Jul 27, 2004 8:23 pm    Post subject: Reply with quote

** Edit adding Form Name to the load_validate .. forgot that bit..

mohrt wrote:
AFAIK, PHP comes with XML parsing functions enabled by default. I'm not sure how far back that goes, but probably enough to rely on? As for compiling, It would be fairly trivial to convert the XML file into an associative array that could be written to a compiled file.


Basically I like it, and would like to help if you have the need.

@Boots, .. you're right of course.. but I lacked the (desire) to go in detail. I don't work with designers that do anything but design I use setups like that in the templates for my clients that want to be able to change their site criteria simply, but don't want a whole backend office (read, don't want to pay for). Be that as it may, you are right in your admonishments and clarity. On top of that, it was a bad example. I was really just trying to clear my head on 'what is validation' and 'what was important' . I think I did that well enough, if you over look glaring latenight redeyed snafus.

It crosses my mind that if you are going to take the step to a config file setup, .. then perhaps using it more aggressivly would be better.

Form partial for idea :
Code:


{load_validate file="main.vals" section="signup" formname="signup"}
<form name="signup" method=POST>
  {if $error_username} $error_username<br />{/if}
  <input type=text name=username value=""> <br />

  {if $isNotEmpty_fname} $isNotEmpty_fname the First Name<br />{/if}
  {if $isNotNumeric_fname} $isNotNumeric_fname the  First Name<br />
{/if}
 {if $Greater_fname} Please Confirm this is your First Name $Greater_frname<br />Or type in new value<br />
{/if}
<input type=text name=fname value="{if $fname}{$fname}{/if}" >



Yes, no labels or other stuff, .. you get the point I'm sure.

then config

Code:


#main validation file #
<defaults>
   <dfield name="namefield" multierror="FALSE" preferror="0">
          <criteria name="isNotEmpty" >
               <errormessage="You Must supply a value for " />
               <errorvar_prefix="isNotEmpty_" />
               <errorvar_type="string" />
         </criteria>
 
          <criteria name="isNotNumeric" />
               <errormessage="Please use only letters in " />
               <errorvar_prefix="isNotNumeric_" />
               <errorvar_type="string" />
         </criteria>

          <criteria name="lengthIsGreater" minsize="3" />
               <errormessage=" " />
               <errorvar_prefix="Greater_" />
               <errorvar_type="confirm_yes_no" />
         </criteria>

         <transform name="trim" />


</defaults>

####[signup]
<form name="signup">
   <field name="username" multierror="FALSE">
       <tag name="username_is_empty">
           <criteria name="isNotEmpty" >
               <errormessage="To sign on you need a User Name " />
               <errorvar="error_username" />
               <errorvar_type="string" />         
           </criteria>
           <criteria name="isValidUserName" >
               <errormessage="User Name must be between 6 and 10 characters " />
               <errorvar="error_username" />
               <errorvar_type="string" />         
           </criteria>
           <transform name="trim" />
       </tag>
     <defaultcritera ="FALSE" />
   </field>

   <field name="fname">
     <defaultcritera ="namefield" />
   </field>
   <field name="lname">
     <defaultcritera ="namefield" />
   </field>
   <field name="city">
     <defaultcritera ="namefield" />
   </field>
 
</form>



That actully feels kinda good there, it seems like with only a few keys qute a bit could be done, and it seems readable to me. I don't see it taking much for the designer to be able to open the validation file indicated and find the error vars, what their names are and what the validation criteria is being called for each field. Those not listed are not being validated.

One of the thngs I noticed (And I'm aware that it was just a sketch) was that the frist example showed a single criteria being called for a field that showed two possible in the config... that felt 'confusing' to a non-coder'. Put in like this, telling the designer straight out, 'go check the file' .. feels less confusing and shows them what they need to plan for in one spot. They could cover several forms at the same time, and have a clear outline.

I liked your idea of a default set as well, and this seemed to work with the existing config file layout (except its XML of course). A basic criteria could fit a lot of fields like this very quickly, and reduce possible errors and bugs.

Just a thought off the top of my head as well. If it sparks a creative tone, great. If it serves as a template for what you definitly don't want, that , in its own way is valuable as well.

webadept
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Smarty Forum Index -> Add-ons All times are GMT
Goto page Previous  1, 2, 3 ... 10, 11, 12 ... 16, 17, 18  Next
Page 11 of 18

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP