Smarty

[mohrt]

[boots]

[mohrt]

Now we're getting somewhere 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

[boots]

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

[mohrt]

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.

[mohrt]

Cocoon forms have a very similar approach.

http://cocoon.apache.org/2.1/userdocs/forms/

[boots]

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?

[webadept]

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

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.

[boots]

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.

[webadept]

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

[mohrt]

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

[boots]

@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.

[boots]

@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.

[mohrt]

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.

[webadept]

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