Entries Tagged 'Quests/FormProcessor' ↓

I’ve created a “mockup”:/tmp/create_rules.html of the main page of the rulecreator front-end. Please give me any feedback you can. This is a “concept” mockup - the tables shouldn’t be present in the final version.

If you can write/help with the necessary javascript then please do volunteer - I don’t know any javascript, so it’s going to be a slow project/steep learning curve if I have to write it all!

I’d very much like this to be a community effort - there are far more talented people than myself out there, and so the finished creation will be much better with your help.

Time for a progress update, although I don’t think I’m ready to release any code yet (if someone could donate CVS hosting that would be great - I don’t want to set up a “sourceforge”:http://sf.net or “Tigris”:/http://www.tigris.org project just for FormProcessor) as it’s still being hacked.

The biggest change is that I’ve moved to using XML_HTMLSax instead of PHP’s XML extension. This means that it’s roughtly 5 times slower (although I’ve not compared the two versions of my script together, only run the test that comes with XML_HTMLSax) but should hope with less well-formed XHTML, and won’t get stuck on @ @ any more.

There is also a rule parser now, and the rules are stored in XML files now. One point I’ve still not decided: _should the error messages be in the form’s file or in the XML file?_ Any formatting applied to the rules is presentation logic, but the rules are business logic… tell me what you think.

Below is a sample of the XML file. Currently I expect a separate file for each form, so no mechanism has been provided for extracting one specific form from a file. However, it should be easy enough to implement if required.

<br /> <form> <p> You did not enter your name</p> <p> Your name must consist <em>only</em> of letters</p> <p> You are not a good enough computer programmer!</p> <p> You did not enter an email address</p> <p> Sorry, but the email address you entered isn’t valid.</p> </form> <p>

I’ve started on a front end now for generating the rulesets. And guess what? I can’t use FormProcessor in its current incarnation to fill in the fields. Why? Well, for ease of processing in the script, I’m giving my @input@ tags names like @rule[]@ or @entry[fieldname]@ so that I get arrays in PHP automatically generated. And FormProcessor doesn’t understand field names containing [] produce arrays. I guess I’m going to have to modify it at some stage to do so, but I think it would take quite a bit of work and probably slow down the script.

Nothing’s ever as straightforward as you think it should be

“Formsess”:http://www.katana-inc.com/formsess looks to be quite similar, although not the same as my goals. Designed to be used with Smarty, I think (from a cursory glance) that it would work on its own. Formsess uses rules embedded in the HTML, however instead of using the HTML form elements it has its own tags.

For more details “view the Formsess manual”:http://www.katana-inc.com/formsess/manual/en/

OK, let me list where I’ve got to now.

* The FormProcessor Class is no longer passed a string containing the form fields. Instead you now load an XHTML file and select the form in that file you want to manipulate. The selection is based on the id given to the @

I’ve uploaded a newer version of the “FormProcessor”:http://peter.mapledesign.co.uk/quests/formprocessor.

h3. Changes

* Added support for radio buttons, checkboxes and selects.
* Maybe a few other things I’ve forgotten
h3. Current todo list:

# Write a rule extractor to work from an XML file
# Make it work with select fields with the @multiple@ attribute. This is rather important for me, as one of my projects uses a few of these fields. So what are the current problems? Well
## The code always expects a string rather than an array of fields
## Because the @select@ has to have the name @whatever[]@ when the XML parser goes through the XHTML form looking for fields named @whatever@ that match the contents of the array @$_POST['whatever']@ it doesn’t find any. So the selection does not get remembered, and the field cannot be validated.
# Convert the code to use HTML_SAX - a more liberal parser
# Allow the class to work with forms embedded in a XHTML page, and select which form to work on when more than one form is present in the page.

h3. Features I’d like to add:

* If you have a group of radio buttons inside a @fieldset@, I’d like to be able to add the .invalid class to the fieldset tag rather than the radio buttons.

And a couple of links from “Sitepoint Forums”:http://www.sitepointforums.com on form validation

* “Form Validation (cont.) “:http://www.sitepointforums.com/showthread.php?threadid=121129
* “Form Validation”:http://www.sitepointforums.com/showthread.php?threadid=77563 - with code from Vincent Oostind, but I think his approach is overkill
* “Advanced Form Validation”:http://www.sitepointforums.com/showthread.php?threadid=114185 - A thread by Simon Willison on his FormProcessor class, discussing the best way to handle validation.

On a related note, I stumbled across “dbForm”:http://dbform.sourceforge.net/ today, which is similar to PHPLens (but I think more basic) and of course free. I think it’ll find its way into my latest project…

Can anyone recommend a pre-written validation library, suitable for use with form data? I’m not particularly happy with the validation routine in Simon Willison’s FormProcessor class, as it’s just one method within the class - I’d like it to be a separate class as I believe this would enforce the separation better.

*Update (2003/09/04):* Here’s some “Python form validation solutions”:http://toulouse.amber.org/archives/2003/09/03/python_form_and_validation_kits.html as a reference.

I’ve posted the current state of the code for anyone that wants to peruse it.

h3. Changes from “Simon’s code”:http://simon.incutio.com/archive/2003/06/17/theHolyGrail

* Added code to make sure radio/checkbox/textarea/select fields retain their values
** Does not work with select boxes that allow you to select multiple values
* Added new tag: <hiddeninputs />. This prints out any @$_POST@ variables that do not already have fields in the form as hidden inputs.
* Made the class handle @hr@ tags correctly.

There may be others, but I’ve forgotten them
Next stage is to add validation rules to these new fields. With select fields and radio buttons things start to get _fun_
“View the code”:http://peter.mapledesign.co.uk/quests/formprocessor/code/0.2
“Run the demo”:http://peter.mapledesign.co.uk/quests/formprocessor/code/0.2/Myformdemo.php

I’ve come across another form implementation that impressed me. “SmartForms”:http://www.roadsend.com/siteManager/siteManager_HTML/x1201.html from the “Roadsend SiteManager”:http://www.roadsend.com/siteManager seems to have many good features. I like the specific form templates idea in particular, as this is half-way to what I want to achieve. If SmartForms was available as a stand-alone library (which as far as I know it isn’t) then I’d consider using it at the present time (at least until I’ve developed something that pleases me more).

Jim (one of the owners of “FluidHosting (http://www.fluidhosting.com/)”:http://www.shareasale.com/r.cfm?B=8239&U=71070&M=2791, the company where I host) also has a nifty form generation class that has very good multipage form support - unfortunately he hasn’t shared the code!

I can see why these two libraries are good, but I want to implement something that will work with an already existing XHTML(eXtensible HypterText Markup Language) form, rather than generating the form+table (or form and then assigning into a template). For projects where you want to generate the forms programmatically, such as those where you are building forms to edit database records, yes, I think these form _generation_ libraries are excellent solutions. But for smaller sites, where you have only a set number of forms and can design each by hand, or sites where a designer wants to have full visual control, I don’t think the traditional approach is the best. Yes, the “SmartForms”:http://www.roadsend.com/siteManager/siteManager_HTML/x1201.html Form Templates give the designer much more control, but not full visual editing capabilities of the form elements. Want to tweak the class attributes, and see the changes in place? Try doing that with any traditional solution using normal designer tools (such as “Dreamweaver (not recommended)”:http://www.macromedia.com/dreamweaver/ or “TopStyle (recommended)”:http://www.bradsoft.com/).

I still have parts of my solution to think out. For example, with pure XHTML(eXtensible HypterText Markup Language) forms, how am I going to populate a select box with options from a database? I think this can be done in the PHP script using the XML functions, but without putting any *logic attributes* in the XHTML(eXtensible HypterText Markup Language) form? For indeed, that is my goal. I want to make a more complete separation than “Simon Willison”:http://simon.incutio.com/archive/2003/06/17/theHolyGrail achieved. This involves a separate file holding the logic for the form. Eventually this will be XML (but should it be SML(Simple Markup Language - a simplified form of XML with more tags but no attributes) or XML–you advise!) but for now I’m using an array to save me writing a processor at this time. Current trials are going OK, but learning how to write PHP code for SAX processing is taking me a while - figuring out how to replace self-closed tags with new content took a while (and I’ve not mastered it yet - the way I did it for hidden inputs seems to be very clunky)

That’s enough writing for this evening - maybe I’ll get more coding done tomorrow And I will post some code… eventually.