-- Mark Maynereid <[EMAIL PROTECTED]> wrote
(on Friday, 30 November 2007, 07:35 AM -0800):
> You mention a "prototype" below that starts to bring the proposals together.
> I am not clear if I should be able to see it yet going by the text. If I
> can, a link would be appreciated. If not, don't mean to hassle, just
> wondered if it was public as such yet.
It's in the laboratory:
http://framework.zend.com/svn/laboratory/Zend_Form
You can checkout from there using SVN, or simply browse the code.
> If I may also just offer some comments on what I've seen in the proposals so
> far, I was bowled over by what Mitchell has done:
> http://mitchellhashimoto.com/zend-form I had zero problems getting my head
> around that and he even has two slick but beautifully minimalist demos.
>
> Sadly Mitchel's doesn't seem to comprise element type hinting, but Jurrien's
> proposal does albeit I'm finding it slower going working it all out, and
> with that I could potentially generate form html on the fly right?
This is exactly what I was getting at about picking the strengths of
each proposal. In the prototype, I have element level hinting, and it
uses view helpers for generating the actual HTML for elements (and I've
included the ability to set the view helper to use for each element, its
label, and its error messages, as well as a "composite" helper that
renders all three in a particular layout). Basically, it means that you
can do this in your view script:
<form action="<?= $this->formAction ?>" method="post">
<?= $this->form ?>
<?= $this->formSubmit('go', 'Go') ?>
</form>
and be done. (I'll add the ability to specify the form action, method,
encoding, and any other attributes to the Zend_Form_Abstract class in
the near future, which will simplify that to just the "<?= $this->form ?>"
line.) The nice part is that there are many levels where you can
customize the HTML generation, which will result in you being able to
rely on as little or as much HTML generation as you want.
Other element level hinting includes the ability to specify what
validators and filters you want per-element.
> I've got a forms intensive project to do and I am dreading writing out
> all the repetitive HTML for it. Only a few of them should really need
> hand crafting. For all the criticism I've read on generating form
> html, I think it's fantastic at saving time when knocking out demos or
> even in production provided of course you can always implement hand
> crafted versions where preferred. Best of both worlds surely?
Yep. The way the prototype works, you can render the form using the
helpers associated with each element, or you can hand craft your own
form, and simply rely on the validation and filtering capabilities. It
also uses the same API (though I need to implement the interface) as
Zend_Validate, so using a form is as simple as:
if (!$form->isValid()) {
// get messages...
$messages = $form->getMessages();
// render, or something...
} else {
$values = $messages->getValues();
$model->save($values);
}
There's still some work to be done on it, as you'll see if you look at
it closely. For instance, the current iteration has no concept of
multi-page forms, nor of validating single elements (though you can
validate a single element easily by pulling the element from the form
object).
> Matthew Weier O'Phinney-3 wrote:
> > As announced on this list previously, in addition to reviewing the
> > proposals in the wiki, I've also been reviewing form solutions in other
> > frameworks, both PHP and otherwise, to see what features they offer,
> > what works well, what doesn't, and what common issues are. Basically,
> > I'm trying to build a best of breed combining all the ideas -- I'm not
> > trying to usurp the work others have done, but rather gather all the
> > best ideas and build an implementation built on those. If you look
> > carefully at the prototype I've done, you'll see that it uses code and
> > ideas from each of the proposals.
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
