Hi Simon,
One of the things I tried to accomplish with this Zend_Form setup is
flexibility. Seeing as form handeling is a delicate subject, I wanted
developers to be able to use Zend_Form as much or as little as they
would like.
The usage of helpers is therefore completely optional. :)
The factory approach wasn't my initial choice either, but it makes
the usage of Zend_Form a lot easier and saves many lines of code.
After a days work of refactoring I made a clean cut between the
Zend_Form factory class and the real form "pages".
Again, this made the factory approach optional. I'll give an example:
$form = Zend_Form::get('myForm', Zend_Form::DATASOURCE_POST);
could be rewritten as:
$form = new Zend_Form_Page();
$form->setName('myForm');
$form->setAction('/request/uri');
$form->setInputData($_POST);
Or, if you have a custom form page class (with name and action
already setup):
/** class My_Form extends Zend_Form_Page */
$form = new My_Form();
$form->setInputData($_POST);
The flexibility of the Zend_Form isn't documented well enough in the
proposal yet (time...). I personally see this flexibility as a major
plus to this approach, but it also brings complexity.
I'd be interested to see how a Zend_Db_Table approach would work for
Zend_Form. I touched this sort of implementation briefly, but then I
started a massive refactoring spree. ;)
There is a link to a SVN repo in the proposal by the way, if you like
to have a look at what's been done so far.
Cheers!
Jurriën
On 08 Aug 2007, at 09:51, Simon Mundy wrote:
Hi Jurriën
At first glance I can see some immediate improvements over mine and
Ralf's proposal. One thing particularly that interested me was the
idea of an MVC helper that could be responsible for telling a form
what data it has received by interacting with the Request object -
this would address a concern that Martel had about performance and
properly separating the logic from the presentation, rule
processing and filtering. However as a long-term proposition I
think that the Form should allow population and creation by means
other than just integration - it should be able to stand alone.
I'm not a huge fan of the factory - I think we'd lose a lot of the
graceful class extension by forcing a factory class upon it and
then supply user paths, prefixes, etc. that could be avoided by
inheritance. I am still a big fan of the Zend_Db_Table approach,
whereby methods such as 'init()', 'preDispatch', 'postDispatch' etc
could be leveraged to allow a self-contained 'static' class (i.e.
the logic is hardcoded into the Form Model) or to build a dynamic
form from a config file.
I'd like to flesh out these ideas in my head a little - I started
trying to recode my original proposal but a) time got away and b)
wanted to get the component leaders to respond as well so we can,
as you say, get some good community feedback.
Look forward to the email ping-pong Jurriën! :)
Cheers
Hi all,
A few days ago I posted a new Zend_Form proposal. It takes a
somewhat different approach than Simon & Ralf's proposal.
It has been discussed a few times on #zftalk, but I feel that it
could really use some community input.
Please read it and comment on it at:
http://framework.zend.com/wiki/pages/viewpage.action?pageId=36061
Thanks!
Jurriën
--
Simon Mundy | Director | PEPTOLAB
""" " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" "
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3
9654 4124
http://www.peptolab.com
