Quantcast

Forms now in master!

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Forms now in master!

weierophinney
Administrator
Hey, all!

Rob Allen has finished reviewing my feature/forms branch, and merged it
to master!

This "component" is actually > 2 components:

 * A new Zend\Stdlib\Hydrator, which provides an interface for
   populating an object with values, as well as extracting them. Right
   now, we have two strategies, ObjectProperty, which translates back
   and forth from public properties, and ArraySerializer, which uses
   the combination getArrayCopy/exchangeArray() or populate().

 * A new Zend\Filter\InputFilter component. This allows you to define
   Input objects, which contain filters and validators and a few other
   pieces of metadata, and InputFilter objects, which compose Input and
   InputFilter objects. Basically, this is a more object-oriented
   version of Zend_Filter_Input. A Factory is also provided to make
   creating individual inputs or full input filters from arrays or
   traversable objects; the default InputFilter implementation is
   actually factory-backed, making it trivially easy to create an input
   filter from configuration or array notation.

 * Zend\Form, which consists of two distinct pieces:
   * Forms, Fieldsets, and Elements. These primarily compose attributes,
     and, in the case of Fieldsets and Forms, Elements and Fieldsets.
     Forms also compose an input filter, and allow binding an object to
     the form. Binding allows (a) populating element values from the
     object, and (b) populating the object from the *validated* values;
     this is done via an attached Hydrator (see above). Elements can
     hint to the form how their corresponding Input in the input filter
     should look, if not already defined.

     Two specialized elements are shipped: Csrf and Captcha. These
     provide turnkey solutions for CSRF protection and CAPTCHA support,
     respectively.

     A factory is available to allow creating all elements, fieldsets,
     and forms, and proxies to the InputFilter factory to allow creating
     the associated InputFilter. The default Form implementation is
     factory-backed, again to make creating a form and its elements
     easy.

   * View helpers. There are Zend\Form-specific view helpers, including
     Form, FormCaptcha, FormElement (which proxies to other helpers),
     FormElementErrors, FormInput, FormLabel, FormMultiCheckbox, FormRadio,
     FormSelect, and FormTextarea. These take an Element (or Form, in
     the case of Form), and create HTML markup from it.

I'm still working on documentation, but Rob and I have both created some
form samples for you to look at; the unit tests also provide good usage
cases and examples.

 * My PhlyContact module -- on the feature/zf2-forms branch:
 
       http://bit.ly/Jh9AX6

   This demonstrates consumption by a controller, extending an input
   filter, and extending a form. It's a trivial example, and only
   demonstrates a small number of capabilities.

   A view script is here:

       http://bit.ly/IWBGnN

   It's a bit repetitive, but shows the typical interactions and
   workflow. One plan is to provide some turnkey view helpers for
   generating common element styles (such as <div>, <dt>/<dd>, and plain
   <label><element></label> styles).

 * Rob has some examples here:
 
       https://github.com/akrabat/ZF2TestApp/tree/master/module/Form
       https://github.com/akrabat/zf2-tutorial/tree/master/module/Album/src/Album

   These demonstrate model/object binding with the form, as well as all
   the various elements you can try and render at this time.

My todo for beta4 is to get some documentation in place -- the goal is,
at the very least, a quick start and some examples. Ideally, I'd also
like to get in form view helpers for all the HTML4/XHTML1 form input
types, and potentially specialized elements for multi-option element
types (multi-checkbox, radio, and select, basically). If you're
interested in helping, please ping me.

For beta5, the plan is:

 * HTML5 form view helpers and specialized elements (color, date,
   datetime, range, etc.).
 * Builder to take an object with annotations and create a form and
   input filter.

Again, if you're interested in helping with these, ping me.

Please take some time to test the forms in the next few days, if you
can, and provide feedback via pull requests, IRC, the ML, or the issue
tracker.

Thanks!

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

cmple
This post has NOT been accepted by the mailing list yet.
Hi Matthew!

It looks like form elements can't be added =[

considering the following example:
https://github.com/akrabat/ZF2TestApp/tree/master/module/Form

I get the this error message:
Zend\Form\Factory::create expects the $spec["type"] to implement one of Zend\Form\ElementInterface, Zend\Form\FieldsetInterface, or Zend\Form\FormInterface; received Zend\Form\Element

Do I need to make any additional changes or is it a bug?

Thanks!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

duke
This post has NOT been accepted by the mailing list yet.
In reply to this post by weierophinney
Why in PhlyContact/Form (http://bit.ly/Jh9AX6), you put validators in filter class? Is it not better to put them separated in two files to hold separated agreement?

Also I suppose in view modify

echo $this->formInput($form->get('from'));
echo $this->formElementErrors($form->get('from'));

to
echo $this->formInput('from');
echo $this->formElementErrors('from');

echo $this->formTextarea('body');
echo $this->formElementErrors('body')


$this formInput should test if argument is sting and just invoke $form->get('elementName'); So we should define used by default form container. Or we can exchange function to get 2 arguments(element name and form ref) like

echo $this->formInput('form', $form); // if we have more then 1 form at this view.

For single form at view we should define default form like $this->setDefaultForm($form); And then use call function just with single argument :).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

cmple
This post has NOT been accepted by the mailing list yet.
In reply to this post by cmple
cmple wrote
Hi Matthew!

It looks like form elements can't be added =[

considering the following example:
https://github.com/akrabat/ZF2TestApp/tree/master/module/Form

I get the this error message:
Zend\Form\Factory::create expects the $spec["type"] to implement one of Zend\Form\ElementInterface, Zend\Form\FieldsetInterface, or Zend\Form\FormInterface; received Zend\Form\Element

Do I need to make any additional changes or is it a bug?

Thanks!
Anyone???
I can't run my app without forms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

cmple
This post has NOT been accepted by the mailing list yet.
This could be due to my php version (5.3.6),
It looks like a new parameter was added to the is_subclass_of() function:
5.3.9 Added allow_string parameter
http://php.net/manual/en/function.is-subclass-of.php
I'll upgrade my php and retest it :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

booradleys
This post has NOT been accepted by the mailing list yet.
In reply to this post by weierophinney
Hi there,
View Helpers FormMultiCheckbox  and FormRadio render reversed options ($val=>$key):

$id_sexe = new Element('id_sexe');
$id_sexe->setAttributes(array(
'type' => 'radio'
'label' => 'gender',
'options' => array(1=>'man',2=>'woman')
));

generates options like this: <option value='man'>1</option><option value='woman'>2</option>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

cmple
This post has NOT been accepted by the mailing list yet.
In reply to this post by cmple
Hi,
It seems like the form's <button type="submit">< span class="ui-button-text">Button Label< /span></button> element doesn't exist, or am I missing something?


Thanks,
Roman
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

bakura
This post has NOT been accepted by the mailing list yet.
In reply to this post by duke
duke wrote
echo $this->formInput($form->get('from'));
echo $this->formElementErrors($form->get('from'));

to
echo $this->formInput('from');
echo $this->formElementErrors('from');
I highly doubt that this will be possible, because it would imply that a view helper would be aware of the form used, and thus contain a reference to it. In ZF2 every class has its own goal, so the main goal of the form view helpers is : taking an element, and rendering it. Not storing it.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

duke
This post has NOT been accepted by the mailing list yet.
On contrary, It's very easy to implement. In favour of the common using forms in view, so better create method to store default form instead of assign form object as variable to view. We create view model and form in controller so it closely same actions. But it will simplify using form rendering.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

dlu-gs
This post has NOT been accepted by the mailing list yet.
In reply to this post by weierophinney
Hi Matthew, The FormLabel view helper does not escape its output. Is that an intentional behaviour?
David Lukas (dlu-gs)
www.zfdaily.com
JPK
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms now in master!

JPK
This post has NOT been accepted by the mailing list yet.
In reply to this post by weierophinney
Hi

When creating a complex form with multiple sub forms, the form element's names do not preserve the hierarchy.

I have forms set up like below.

class MainForm extends Form
{
  public function __construct($name = null) {
    parent::__construct($name);

    $this->add(array(
      'name' => 'author',
      'attributes' => array('type' => 'text'),
    ));

    $this->add(new MySubForm('FirstSubForm'));

    $this->add(new MySubForm('SecondSubForm'));
  }
}

class MySubForm extends Form
{
  public function __construct($name == null) {
    parent::__construct($name);

    $this->add(array(
      'name' => 'name',
      'attributes' => array('type' => 'text'),
    ));

    $this->add(array(
      'name' => 'note',
      'attributes' => array('type' => 'textarea'),
    ));
  }
}


Rendered html elements have names like below.

* author
* name
* note
* name
* note

Rather than

* author
* FirstSubForm[name]
* FirstSubForm[note]
* SecondSubForm[name]
* SecondSubForm[note]


I tried to extend Zend\Form\Element class to return combined name on getName() function so that FormInput view helper can render the desired names.
However this conflicts with Zend\Form's add function and overwrites the element's name attribute.
And causes further conflicts when I try to set post data to the form or try to access subform objects.

How can I work around these issues?


Jaepil
Loading...