As my RSS manager gets towards the stage of needing an interface, I’ve been looking again at the FormProcessor code. I’m writing forms for adding/editing feeds, filters etc[1] and seeing that the form is the same for each task, I don’t want to duplicate it.
So how do I handle having one button saying “Add X”, while after editing it says “Save Changes” and needs the item’s database ID embedded in the form in a hidden input?
On the “previous site”:http://www.daystarvillas.com I built using FormProcessor I was using the “Smarty”:http://smarty.php.net template engine, and so I used this to swap in/out the buttons on the form. But should this need a template engine, or shoud it be built into FormProcessor?
More importantly, is there a smarter way to do this?
I have thought about having language strings defined somewhere and just switching this, but sometimes I find during sign-up I need to have Next/Prev buttons instead of just Submit, so this doesn’t cut it.
fn1. Yeah, maybe for this task the forms should be generated by PHP from the database structure. But that doesn’t give me total flexibility over the layout 
5 comments ↓
I am extremely excited to see that you are still working on the FormProcessor. Keep it up!
Thanks very much for your kind feedback Joachim.
Do you have any ideas on this problem?
Hi, you are doing a magnificent job with the FormProcessor. I’ve been studying the code, but I fail to see, if you have really implemented support for input-fields with a name-attribute, which is an array (name=type[])?
I’ve looked a bit more on your script, and I’ve stumbled over a few errors in your otherwise brilliant script.
Line 583 and 587: regex should be regexp
I see no reason for adding the PEAR xml-parser. Why not just maintain the parser already built into PHP, as the previous scripts had?
If you are going to be redisplaying the form, e.g. when you want to make multiple additions after eachother always using the same (but blank) form, it will show the values typed on the last submissions. You can solve the problem by adding a variable called $this->_validated, and in $this->validate() set it to true, if the form has been validated successfully. Then do some checks from line 290 and forward.
Again when redisplaying the form, the script will off course not display any errormessages, but it will display whatever is between and . If this contains e.g. , and you added a css-selector with a border, it will display an empty border. You can solve this by adding || count($this->errors) == 0 in line 361.
What is the future plans for the script. Have you found a way to support multiple arrays properly yet?
bq. I’ve looked a bit more on your script, and I’ve stumbled over a few errors in your otherwise brilliant script.
That doesn’t surprise me at all
I have implemented your fixes and suggestions, although not tested those for redisplaying a form. Perhaps you can do so - I’m feeling too lazy to write a new test!
bq. I see no reason for adding the PEAR xml-parser. Why not just maintain the parser already built into PHP, as the previous scripts had?
My reason for changing was one of practicality. My clients often like to do small edits to the templates themselves, and in doing so usually mess up the XHTML. PHP’s parser chokes on badly-formed HTML, and by switching to XML_HTMLSax I could get round the problem of broken pages. I’d prefer not to have a dependency on PEAR, but there’s no alternative at present.
bq. What is the future plans for the script. Have you found a way to support multiple arrays properly yet?
Yes, they’re working. I’m just getting SVN sorted out and then will post a link to the latest code.
Leave a Comment