Quantcast

Forms RFC updated

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

Forms RFC updated

weierophinney
Administrator
I've updated the forms RFC:

    http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms

Among changes:

 * Changed all "subform" terminology to reference "fieldsets". This is
   more in line with standard w3c terminology.
 * Added verbiage for setValidatorGroup() -- this is for partial
   validation of a form, and allows re-using the same form to validate
   different data sets.
 * Revised the section added by Kyle Spraggs on Builders and Model
   binding to clarify a number of points.
 * Added a section on interfaces.

I'd like to discuss the design during tomorrow's IRC meeting, so please
familiarize yourself with it before then! :)

--
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 RFC updated

Stewart Lord
On 3/20/12 3:09 PM, Matthew Weier O'Phinney wrote:
> I've updated the forms RFC:
>
>      http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms


A few more questions about the RFC (via email since I won't be in the
meeting):

1. What exactly are 'input filters'? In ZF1 we had filters and
validators. Are input filters taking on both of these responsibilities?
Input filtering is rather different than input validation, but the RFC
treats these as the same thing.

2. Is the bindInput() method different (conceptually) than a setData()
method (or populate in ZF1)? The word 'bind' suggests that some form of
linkage is established, but your example usage just passes request data.
It would appear from the example and the interface that this method
would be better named setData().

3. I think this was brought up previously, but I don't see mention of a
one line render in the RFC. The 'form' view helper example only renders
the opening tag. I would like to suggest that we have the ability to
render a form with all of it's 'wrapped' elements using a single view
helper call.

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

Re: Forms RFC updated

weierophinney
Administrator
-- Stewart Lord <[hidden email]> wrote
(on Tuesday, 20 March 2012, 09:59 PM -0700):

> On 3/20/12 3:09 PM, Matthew Weier O'Phinney wrote:
> >I've updated the forms RFC:
> >
> >     http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms
>
>
> A few more questions about the RFC (via email since I won't be in
> the meeting):
>
> 1. What exactly are 'input filters'? In ZF1 we had filters and
> validators. Are input filters taking on both of these
> responsibilities? Input filtering is rather different than input
> validation, but the RFC treats these as the same thing.

This is noted in the RFC, under the section heading
"Validation/Normalization":

    MUST allow detaching/attaching validation/normalization chains,
    hereafter titled "input filters"

The proposed InputFilter is analagous to Zend_Filter_Input in ZF1, which
composed both validation and filter chains to provide, well, validation
and normalization. The design is roughly the same, but with a few
changes, primarily to allow context-specific validations and branching,
and also to allow selection of a subset of values to perform operations
on.

> 2. Is the bindInput() method different (conceptually) than a
> setData() method (or populate in ZF1)? The word 'bind' suggests that
> some form of linkage is established, but your example usage just
> passes request data. It would appear from the example and the
> interface that this method would be better named setData().

The "bind" terminology was suggested by Guilherme, and was to indicate
that the form is binding the values provided. A setter method is
probably reasonable terminology as well.

> 3. I think this was brought up previously, but I don't see mention
> of a one line render in the RFC. The 'form' view helper example only
> renders the opening tag. I would like to suggest that we have the
> ability to render a form with all of it's 'wrapped' elements using a
> single view helper call.

I do mention at one point that a helper that handles all the elements in
a given form can be created; I'm unsure if we will provide one
out-of-the-box at this point. However, I will definitely update the
example to have the helper do emitStart() and emitEnd() calls to create
the open/close tags of the form, and thus keep the markup valid for IDEs.

--
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 RFC updated

Stewart Lord
Hi Matthew,

 > The proposed InputFilter is analagous to Zend_Filter_Input in ZF1,
 > which composed both validation and filter chains to provide, well,
 > validation and normalization. The design is roughly the same, but
 > with a few changes, primarily to allow context-specific validations
 > and branching, and also to allow selection of a subset of values to
 > perform operations on.

Thanks. I thought I was familiar with all of ZF, but I have not used
this component before. I will have to get up to speed on it!

 > The "bind" terminology was suggested by Guilherme, and was to indicate
 > that the form is binding the values provided. A setter method is
 > probably reasonable terminology as well.

I'm not sure 'bind' is appropriate unless it provides a lasting linkage
to the data. Does the bindModel method behave differently?

 > I do mention at one point that a helper that handles all the elements
 > in a given form can be created; I'm unsure if we will provide one
 > out-of-the-box at this point.

Sounds good. Please consider this a vote for providing one out-of-the-box.

Regards,
Stew


On 12-03-21 8:50 AM, Matthew Weier O'Phinney wrote:

> -- Stewart Lord<[hidden email]>  wrote
> (on Tuesday, 20 March 2012, 09:59 PM -0700):
>> On 3/20/12 3:09 PM, Matthew Weier O'Phinney wrote:
>>> I've updated the forms RFC:
>>>
>>>      http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms
>>
>>
>> A few more questions about the RFC (via email since I won't be in
>> the meeting):
>>
>> 1. What exactly are 'input filters'? In ZF1 we had filters and
>> validators. Are input filters taking on both of these
>> responsibilities? Input filtering is rather different than input
>> validation, but the RFC treats these as the same thing.
>
> This is noted in the RFC, under the section heading
> "Validation/Normalization":
>
>      MUST allow detaching/attaching validation/normalization chains,
>      hereafter titled "input filters"
>
> The proposed InputFilter is analagous to Zend_Filter_Input in ZF1, which
> composed both validation and filter chains to provide, well, validation
> and normalization. The design is roughly the same, but with a few
> changes, primarily to allow context-specific validations and branching,
> and also to allow selection of a subset of values to perform operations
> on.
>
>> 2. Is the bindInput() method different (conceptually) than a
>> setData() method (or populate in ZF1)? The word 'bind' suggests that
>> some form of linkage is established, but your example usage just
>> passes request data. It would appear from the example and the
>> interface that this method would be better named setData().
>
> The "bind" terminology was suggested by Guilherme, and was to indicate
> that the form is binding the values provided. A setter method is
> probably reasonable terminology as well.
>
>> 3. I think this was brought up previously, but I don't see mention
>> of a one line render in the RFC. The 'form' view helper example only
>> renders the opening tag. I would like to suggest that we have the
>> ability to render a form with all of it's 'wrapped' elements using a
>> single view helper call.
>
> I do mention at one point that a helper that handles all the elements in
> a given form can be created; I'm unsure if we will provide one
> out-of-the-box at this point. However, I will definitely update the
> example to have the helper do emitStart() and emitEnd() calls to create
> the open/close tags of the form, and thus keep the markup valid for IDEs.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC updated

Artur Bodera
In reply to this post by weierophinney
On Tue, Mar 20, 2012 at 11:09 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
I've updated the forms RFC:

   http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms


Two little features I'd like to see:


## HTML5 elements ##

Because it's 2012, it'd nice if we had all drop-in classes for all HTML5 elements (i.e. date, range, email, etc.).
Here is a reference:

Modern browsers support many of those. Older browsers fall back to type="text".



## Element being able to attach validators to the form ##

Either way, we need validation and filtering for the above (we cannot trust the browser). The RFC currently states:

COULD allow form elements to hint which validators/filters are desired, e.g., via annotations; a directive would then tell the form to use this data when retrieving the input filter.

Additionally, form element classes should be able attach validators and  filters by themselves. I.e.:

   $ageElement = $form->addElement("number", "age");

I'd expect the form to now contain a type="number" element, which is then filtered for numerical values. Implementation aside, it's then compatible with ZF1 form behavior when attaching elements.

Another example:

   $captcha = $form->addElement("captcha", "verification", array("adapter" => $di->get("Service\Recaptcha" ) );

I'd expect this new element to use the supplied adapter and attach a Recaptcha validator to the form.


Thoughts ?

-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]




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

Re: Forms RFC updated

weierophinney
Administrator
-- Artur Bodera <[hidden email]> wrote
(on Thursday, 22 March 2012, 11:31 AM +0100):

> On Tue, Mar 20, 2012 at 11:09 PM, Matthew Weier O'Phinney <[hidden email]>
> wrote:
>
>     I've updated the forms RFC:
>
>        http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms
>
>
>
> Two little features I'd like to see:
>
>
> ## HTML5 elements ##
>
> Because it's 2012, it'd nice if we had all drop-in classes for all HTML5
> elements (i.e. date, range, email, etc.).

Yep, planned, though not on the RFC. This will primarily be done in the
view layer as helpers.

<snip>

> ## Element being able to attach validators to the form ##
>
> Either way, we need validation and filtering for the above (we cannot trust the
> browser). The RFC currently states:
>
>     COULD allow form elements to hint which validators/filters are desired,
>     e.g., via annotations; a directive would then tell the form to use this
>     data when retrieving the input filter.
>
> Additionally, form element classes should be able attach validators and
>  filters by themselves. I.e.:
>
>    $ageElement = $form->addElement("number", "age");
>
> I'd expect the form to now contain a type="number" element, which is then
> filtered for numerical values. Implementation aside, it's then compatible with
> ZF1 form behavior when attaching elements.

I'm still working out how the hinting will happen. With annotations,
it's fairly easy, as it's basically a separate scanner that then updates
the form and its input filter. In the case of elements, most likely I'll
need to have a method that can be called to get a list of filters and
validators -- I still have to consider _when_ this should be called,
however (only at validation? or when the form is built?).

> Another example:
>
>    $captcha = $form->addElement("captcha", "verification", array("adapter" =>
> $di->get("Service\Recaptcha" ) );
>
> I'd expect this new element to use the supplied adapter and attach a Recaptcha
> validator to the form.

This is, of course, the argument for having validators/filters directly
on the elements themselves, and having each perform its own validation.
However, that makes use cases where you want to use the full
validation chain in isolation (e.g., for API calls, where forms are
technically not present) next to impossible.

The goal, however, is something similar to what you have above; I'm
still working on the implementation details.

--
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 RFC updated

Artur Bodera
On Thu, Mar 22, 2012 at 2:53 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
The goal, however, is something similar to what you have above; I'm
still working on the implementation details.

Just please remember about usability and connect both of my requests. 

A field of type="number" is expected to receive numbers only. I don't really care about decorators ... It's very important usability feature that auto-generated fields (with new Field\Number() or ->addField("number") ) behave the way they are expected to behave. I understand the need for explicitness in zf2, but not everybody will use ->bindObjects() feature, nor annotations. These two features run in parallel with "basic usage" such as $form = new Form(); $form->addField("datetime", "when") ... etc. Of course there should be an opt-out/override method for power users.


-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]




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

Re: Forms RFC updated

weierophinney
Administrator
-- Artur Bodera <[hidden email]> wrote
(on Thursday, 22 March 2012, 03:19 PM +0100):

> On Thu, Mar 22, 2012 at 2:53 PM, Matthew Weier O'Phinney <[hidden email]>
> wrote:
>
>     The goal, however, is something similar to what you have above; I'm
>     still working on the implementation details.
>
>
> Just please remember about usability and connect both of my requests.
>
> A field of type="number" is expected to receive numbers only. I don't really
> care about decorators ... It's very important usability feature that
> auto-generated fields (with new Field\Number() or ->addField("number") ) behave
> the way they are expected to behave. I understand the need for explicitness in
> zf2, but not everybody will use ->bindObjects() feature, nor annotations. These
> two features run in parallel with "basic usage" such as $form = new Form();
> $form->addField("datetime", "when") ... etc. Of course there should be an
> opt-out/override method for power users.

As I said, this is the goal; I'm still ironing out _implementation_
details.

--
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 RFC updated

leedavis
This post has NOT been accepted by the mailing list yet.
In reply to this post by weierophinney
finally got round to reading this RFC.

And I have to say I'm really excited about the direction Zend_Form is going, namely the Factory, Builder, and model binding part. I've been driving forms from my models for a few years now (http://www.duckheads.co.uk/drive-forms-from-doctrine-entities/) and its saved me so much time. Would be fantastic to see this natively supported.

really looking forward to testing / playing with this feature.

That's it, no questions or issues, just expressing my love.

Lee

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

Re: Forms RFC updated

Coiby
This post has NOT been accepted by the mailing list yet.
Good job!

Marked, review it later:)

2012/3/27 leedavis [via Zend Framework Community] <[hidden email]>
finally got round to reading this RFC.

And I have to say I'm really excited about the direction Zend_Form is going, namely the Factory, Builder, and model binding part. I've been driving forms from my models for a few years now (http://www.duckheads.co.uk/drive-forms-from-doctrine-entities/) and its saved me so much time. Would be fantastic to see this natively supported.

really looking forward to testing / playing with this feature.

That's it, no questions or issues, just expressing my love.

Lee




If you reply to this email, your message will be added to the discussion below:
http://zend-framework-community.634137.n4.nabble.com/Forms-RFC-updated-tp4490535p4508739.html
To unsubscribe from Zend Framework Community, click here.
NAML

Loading...