Quantcast

Forms RFC now up

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

Forms RFC now up

weierophinney
Administrator
I've just put the first draft of the Forms RFC in place:

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

We'll have an initial discussion on it during the IRC meeting Wednesday
at 18:00 UTC (that's likely _today_ for anywhere but parts of the US as
I write this).

--
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 now up

Mike Willbanks
Hi Matthew,

> I've just put the first draft of the Forms RFC in place:
>
>    http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms

Thanks for this! I've put my initial comments on confluence a few
moments ago.  One of the things that I did not mention in several
areas; is that by default it would be good to have the event manager
hooked in by default.  It would also be nice to detect what element
was just added (for the case if you wanted to add an element
afterward).

Feel free to ping me on any of the comments I've made on the RFC.

>
> We'll have an initial discussion on it during the IRC meeting Wednesday
> at 18:00 UTC (that's likely _today_ for anywhere but parts of the US as
> I write this).

It will be _today_ for me in an hour and 15m :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

David Muir-2
In reply to this post by weierophinney
On 02/22/2012 03:10 PM, Matthew Weier O'Phinney wrote:
I've just put the first draft of the Forms RFC in place:

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

We'll have an initial discussion on it during the IRC meeting Wednesday
at 18:00 UTC (that's likely _today_ for anywhere but parts of the US as
I write this). 


Liking it so far!

One pet peeve:
<?php echo $this->form($form); // form opening tag ?>
</form>

Netbeans, and I'd assume most, if not all IDE's will report the above as an error because the opening form tag isn't detected.

Cheers,
David



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

Re: Forms RFC now up

Raphael de Almeida
I think we could use an anonymous function here

<?php
$f = new StdClass();
$f->action = "index.php";
$f->method = "post";
function form($form, $fun_call){
  echo "<form action='$form->action' method='$form->method' >";
  $fun_call();
  echo "</form>";
}
form($f, function(){?>
  <intup type="text" />
<?});



--
[]ão,

Raphael de Almeida

http://raphaeldealmeida.net
http://www.twitter.com/raph_almeida
http://rubyonrio.org | http://phprio.org | http://androidinrio.com.br  http://www.arduinrio.cc | http://dojorio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

guilhermeblanco@gmail.com
Hi,

I think Matthew's proposal is pretty much aligned to what I would envision as a Form solution.
A basic form would be then decoupled into 2 classes at minimum, one responsible for fields/subforms inclusions and the other as serialization/unserialization.
Example:

namespace MyModule\Form\Model;

use Zend\Validator\Constraints as Validate,
    Zend\Filter\Rules as Filter;

use MyModule\Validator\Constraints as CustomValidate;

class LoginFormModel
{
    /**
     * @Validate\NotBlank
     * @Validate\Email(checkMx=true)
     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     * @Filter\Trim
     *
     * @var string
     */
    protected $email;

    /**
     * @Validate\Length(minLength=6, maxLength=25)
     * @CustomValidate\Password()
     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     *
     * @var string
     */
    protected $password;

    // getters and setters here
}

namespace MyModule\Form\Type;

use Zend\Form\FormType,
    Zend\Form\FormBuilder;

class LoginFormType extends FormType
{
    public function buildForm(FormBuilder $builder)
    {
        // Prototype: $builder->add($field, $type, $options);
        $builder->add('email');
        $builder->add('password', 'password');
    }

    public function getName()
    {
        // Allows Form Service to retrieve instance of LoginFormType by doing: $formService->getForm('login-form')
        return 'login-form';
    }

    public function getOptions()
    {
        return array(
            'modelClass' => 'LoginFormModel'
        );
    }
}

// Processing

$loginFormType = $formService->getForm('login-form');
$loginFormType->setModel(new LoginFormModel()); // Optional. Allows update by assigning a pre-built instance
$loginFormType->bind($this->getRequest());

if ($loginFormType->isValid()) {
    // do stuff...
}


// View

<?php echo $this->form($loginFormType); ?>

You could also fill with some default information, by assigning a FormModel instance via setModel with some content to FormType.



Cheers,


On Wed, Feb 22, 2012 at 5:49 AM, Raphael de Almeida <[hidden email]> wrote:
> I think we could use an anonymous function here
>
>> <?php
>> $f = new StdClass();
>> $f->action = "index.php";
>> $f->method = "post";
>> function form($form, $fun_call){
>>   echo "<form action='$form->action' method='$form->method' >";
>>   $fun_call();
>>   echo "</form>";
>> }
>> form($f, function(){?>
>>   <intup type="text" />
>> <?});
>
>
>
>
> --
> []ão,
>
> Raphael de Almeida
>
> http://raphaeldealmeida.net
> http://www.twitter.com/raph_almeida
> http://rubyonrio.org | http://phprio.org | http://androidinrio.com.br  http://www.arduinrio.cc | http://dojorio.org



--
Guilherme Blanco
MSN: [hidden email]
GTalk: guilhermeblanco
Toronto - ON/Canada

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

Re: Forms RFC now up

SpiffyJr
That's very very similar to what I had done with SpiffyForm. A slightly outdated example can be seen at https://github.com/SpiffyJr/SpiffyForm/blob/master/docs/EXAMPLES.md. It has listeners built-in that can read annotations from various sources (Doctrine ORM, Mongo, generic objects, etc). I'm not too sure if a builder should be part of the Zend core or would be better left to module developers but I'm a huge advocate of some sort of automated form builder making it into the core if possible.

Kyle S
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare



On Wed, Feb 22, 2012 at 10:19 AM, [hidden email] <[hidden email]> wrote:
Hi,

I think Matthew's proposal is pretty much aligned to what I would envision as a Form solution.
A basic form would be then decoupled into 2 classes at minimum, one responsible for fields/subforms inclusions and the other as serialization/unserialization.
Example:

namespace MyModule\Form\Model;

use Zend\Validator\Constraints as Validate,
    Zend\Filter\Rules as Filter;

use MyModule\Validator\Constraints as CustomValidate;

class LoginFormModel
{
    /**
     * @Validate\NotBlank
     * @Validate\Email(checkMx=true)
     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     * @Filter\Trim
     *
     * @var string
     */
    protected $email;

    /**
     * @Validate\Length(minLength=6, maxLength=25)
     * @CustomValidate\Password()
     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     *
     * @var string
     */
    protected $password;

    // getters and setters here
}

namespace MyModule\Form\Type;

use Zend\Form\FormType,
    Zend\Form\FormBuilder;

class LoginFormType extends FormType
{
    public function buildForm(FormBuilder $builder)
    {
        // Prototype: $builder->add($field, $type, $options);
        $builder->add('email');
        $builder->add('password', 'password');
    }

    public function getName()
    {
        // Allows Form Service to retrieve instance of LoginFormType by doing: $formService->getForm('login-form')
        return 'login-form';
    }

    public function getOptions()
    {
        return array(
            'modelClass' => 'LoginFormModel'
        );
    }
}

// Processing

$loginFormType = $formService->getForm('login-form');
$loginFormType->setModel(new LoginFormModel()); // Optional. Allows update by assigning a pre-built instance
$loginFormType->bind($this->getRequest());

if ($loginFormType->isValid()) {
    // do stuff...
}


// View

<?php echo $this->form($loginFormType); ?>

You could also fill with some default information, by assigning a FormModel instance via setModel with some content to FormType.



Cheers,


On Wed, Feb 22, 2012 at 5:49 AM, Raphael de Almeida <[hidden email]> wrote:
> I think we could use an anonymous function here
>
>> <?php
>> $f = new StdClass();
>> $f->action = "index.php";
>> $f->method = "post";
>> function form($form, $fun_call){
>>   echo "<form action='$form->action' method='$form->method' >";
>>   $fun_call();
>>   echo "</form>";
>> }
>> form($f, function(){?>
>>   <intup type="text" />
>> <?});
>
>
>
>
> --
> []ão,
>
> Raphael de Almeida
>
> http://raphaeldealmeida.net
> http://www.twitter.com/raph_almeida
> http://rubyonrio.org | http://phprio.org | http://androidinrio.com.br  http://www.arduinrio.cc | http://dojorio.org



--
Guilherme Blanco
MSN: [hidden email]
GTalk: guilhermeblanco
Toronto - ON/Canada


Kyle S
blogs @ www.spiffyjr.me
github @ www.github.com/spiffyjr
follow @ www.twitter.com/spiffyjr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

SpiffyJr
I updated the RFC with thoughts that are very close to what you (guilehermeblanco) submitted. I'd appreciate any feedback on the updates.


Thanks!

Kyle S
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare



On Wed, Feb 22, 2012 at 11:03 AM, Kyle S <[hidden email]> wrote:
That's very very similar to what I had done with SpiffyForm. A slightly outdated example can be seen at https://github.com/SpiffyJr/SpiffyForm/blob/master/docs/EXAMPLES.md. It has listeners built-in that can read annotations from various sources (Doctrine ORM, Mongo, generic objects, etc). I'm not too sure if a builder should be part of the Zend core or would be better left to module developers but I'm a huge advocate of some sort of automated form builder making it into the core if possible.

Kyle S
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare



On Wed, Feb 22, 2012 at 10:19 AM, [hidden email] <[hidden email]> wrote:
Hi,

I think Matthew's proposal is pretty much aligned to what I would envision as a Form solution.
A basic form would be then decoupled into 2 classes at minimum, one responsible for fields/subforms inclusions and the other as serialization/unserialization.
Example:

namespace MyModule\Form\Model;

use Zend\Validator\Constraints as Validate,
    Zend\Filter\Rules as Filter;

use MyModule\Validator\Constraints as CustomValidate;

class LoginFormModel
{
    /**
     * @Validate\NotBlank
     * @Validate\Email(checkMx=true)
     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     * @Filter\Trim
     *
     * @var string
     */
    protected $email;

    /**
     * @Validate\Length(minLength=6, maxLength=25)
     * @CustomValidate\Password()
     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     *
     * @var string
     */
    protected $password;

    // getters and setters here
}

namespace MyModule\Form\Type;

use Zend\Form\FormType,
    Zend\Form\FormBuilder;

class LoginFormType extends FormType
{
    public function buildForm(FormBuilder $builder)
    {
        // Prototype: $builder->add($field, $type, $options);
        $builder->add('email');
        $builder->add('password', 'password');
    }

    public function getName()
    {
        // Allows Form Service to retrieve instance of LoginFormType by doing: $formService->getForm('login-form')
        return 'login-form';
    }

    public function getOptions()
    {
        return array(
            'modelClass' => 'LoginFormModel'
        );
    }
}

// Processing

$loginFormType = $formService->getForm('login-form');
$loginFormType->setModel(new LoginFormModel()); // Optional. Allows update by assigning a pre-built instance
$loginFormType->bind($this->getRequest());

if ($loginFormType->isValid()) {
    // do stuff...
}


// View

<?php echo $this->form($loginFormType); ?>

You could also fill with some default information, by assigning a FormModel instance via setModel with some content to FormType.



Cheers,


On Wed, Feb 22, 2012 at 5:49 AM, Raphael de Almeida <[hidden email]> wrote:
> I think we could use an anonymous function here
>
>> <?php
>> $f = new StdClass();
>> $f->action = "index.php";
>> $f->method = "post";
>> function form($form, $fun_call){
>>   echo "<form action='$form->action' method='$form->method' >";
>>   $fun_call();
>>   echo "</form>";
>> }
>> form($f, function(){?>
>>   <intup type="text" />
>> <?});
>
>
>
>
> --
> []ão,
>
> Raphael de Almeida
>
> http://raphaeldealmeida.net
> http://www.twitter.com/raph_almeida
> http://rubyonrio.org | http://phprio.org | http://androidinrio.com.br  http://www.arduinrio.cc | http://dojorio.org



--
Guilherme Blanco
MSN: [hidden email]
GTalk: guilhermeblanco
Toronto - ON/Canada



Kyle S
blogs @ www.spiffyjr.me
github @ www.github.com/spiffyjr
follow @ www.twitter.com/spiffyjr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

SpiffyJr
This post has NOT been accepted by the mailing list yet.
Not a single comment! Come on! :)
Kyle S
blogs @ www.spiffyjr.me
github @ www.github.com/spiffyjr
follow @ www.twitter.com/spiffyjr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

intellix
This post has NOT been accepted by the mailing list yet.
This post was updated on .
Frontender here again:

"I'd say that the most common practise in our development is to create the decorator stack first, then create the form and don't care about how will they look - they will be awesome"

That's ok when you don't need to care about how a form will look and want to just throw it on the page. The current way (ZF1) handles form decorators really winds me up and I agree with that the handling of how the form 'looks' should be handled by the view.

Let the backender worry about how a form is validated, filtered and let me decide how it should look. One little thing I like to do is to have a label on top of the field that only disappears when the field has a value or the user starts typing. This doesn't work in all situations so sometimes I want it to be printed differently in HTML like so:

<div class="labelledField">
     <label for="name">Name</label>
     <input name="name" id="name" type="text" />
     <div class="errorTooltip">
         <ul>
             <li>Name can only contain letters</li>   
         </ul>
     </div>
</div>

The label is placed on top of the input field, when clicked it dims and when you type it disappears. When you empty the form the label appears again. Errors are displayed in a tooltip. Just a nice looking trick and in ZF1 it's a bit hacky to even achieve this.

Alot of stuff in terms of frontend requires wrapping items in particular ways and a backender doesn't understand what you want to do so shouldn't be dictating how its given to me.

What I currently have is a folder of form partial templates like labeledField.phtml which prints out the label, input field, errors in a particular way. What I don't like is that inside the FormModel I have to hack it to disable decorators and choose which template I want to use there.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

guilhermeblanco@gmail.com
In reply to this post by SpiffyJr
Hi Kyle,

There are some changes I'd like to do in the RFC now.
It's much more complete than the original one, way more flexible, but I still think it's not ideal.

The first item to modify is how you bind information to form. My original idea was bind($request), but this doesn't seem enough. Sometimes, you may want to bind extra information, so I think we need to decouple the bind into 2 methods: bindRequest and bindData. The first one binds exclusively the request (and not only post() as per your example), because there may have also arguments that come from query string. The second is an internal call from bindRequest after some internal processment, which allows to bind calculated information, for example, default values by a specific page. Does this make any sense to you?

The second item to modify is how the elements are built. Leaving everything to the FormModel is not good, specially because you may want to reuse this Model under different perspectives. Let's make a simple example:
Suppose I want to map my FormModel into actually an Entity. I could have a page that only allows User to modify his email for example. If you map the Form elements into the User entity, how can you make this form available, that only displays the input type="email" field?
That's why you need the FormType to map specific functionality into FormModel. I'd call it group, interest or intention. Then, you could map different groups into FormModel, which could act with a single mapping to multiple FormTypes. Also, non-grouped validation rules are globally applied. Your FormTypes are actually your form elements mappings, including sub-forms inclusions.
Let me try to put into a real world example:

namespace MyModule\Entity;

use Zend\Validator\Constraints as Validate,
    Zend\Filter\Rules as Filter;

use Doctrine\ORM\Mapping as ORM;

use MyModule\Validator\Constraints as CustomValidate;

/**
 * User entity
  *
  * @ORM\Entity
 * @ORM\Table(name="users")
  */
class User
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     *
     * @Validate\Type("integer")
     *
     * @var integer
     */
    protected $id;

    /**
     * @ORM\Column(type="string", length="50")
     *
     * @Validate\Group(name="create-user", constraints={
     *     @Validate\Unique(field="name")
     * })
     *
     * @Validate\NotBlank
     * @Validate\Length(maxLength="50")
     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     * @Filter\Trim
     *
     * @var string
     */
    protected $name;

    /**
     * @ORM\Column(type="string", length="150")
     *
     * @Validate\Group(name="update-email", constraints={
     *     @CustomValidate\NotSame(field="email")
     * })

     *
     * @Validate\NotBlank
     * @Validate\Email(checkMx=true)
     * @Validate\Length(maxLength=150)

     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     * @Filter\Trim
     *
     * @var string
     */
    protected $email;
}

namespace MyModule\Form\Type;

use Zend\Form\FormType,
    Zend\Form\FormBuilder;

class UpdateEmailFormType extends FormType
{
    public function buildForm(FormBuilder $builder)
    {
        $builder->add('email', 'email', array('label' => 'Email'));
    }

    public function getName()
    {
        return 'update-email-form';
    }

    public function getOptions()
    {
        return array(
            'modelClass' => 'MyModule\Entity\User',
            'interest'   => 'update-email' // group, interest or intention. Do you have a better name?
        );
    }
}

// EntityService is a mapped DI service which supports
// RESTful-like operations: get, filter, post, put and delete

//
// Processing

$user = $userService->get(1);


$updateEmailFormType = $formService->getForm('update-email-form');
$updateEmailFormType->setModel($user);
$updateEmailFormType->bindRequest($this->getRequest());

if ($updateEmailFormType->isValid()) {
    $userService->post($user);
}


The third change is consistency of methods. When you set the FormModel, you use the $formType->setModel(). It would be consistent to grab the FormModel by using $formType->getModel().

The fourth change is about unique responsibilities. Passing the $formType to view for rendering is far from ideal, specially because you would be including rendering logic on a class that was supposed to only deal with form elements mapping (not rendering). Ideally, you delegate this rendering responsibility to an auxiliar class, like a FormRenderer or FormView, whatever you want to name it. This class would then know how to render the form.
Inside of Controller, you just $formType->createView() or $formType->createRenderer().

Finally, the way it was structured the FormType, allows people to create their custom ElementTypes. All they need to do is attach their custom ElementTypes into Form element types. Also, if well defined, the prototype of FormBuilder->add could accept not only a string in $type, but also an ElementType instance. Example:

$builder->add(
    'gender',
    new GenderType('male', 'female', 'trans', ...),
    array('label' => 'Gender')
);




Does this makes sense to you?


Cheers,


On Thu, Feb 23, 2012 at 12:04 PM, Kyle S <[hidden email]> wrote:
I updated the RFC with thoughts that are very close to what you (guilehermeblanco) submitted. I'd appreciate any feedback on the updates.


Thanks!


Kyle S
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare



On Wed, Feb 22, 2012 at 11:03 AM, Kyle S <[hidden email]> wrote:
That's very very similar to what I had done with SpiffyForm. A slightly outdated example can be seen at https://github.com/SpiffyJr/SpiffyForm/blob/master/docs/EXAMPLES.md. It has listeners built-in that can read annotations from various sources (Doctrine ORM, Mongo, generic objects, etc). I'm not too sure if a builder should be part of the Zend core or would be better left to module developers but I'm a huge advocate of some sort of automated form builder making it into the core if possible.

Kyle S
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare



On Wed, Feb 22, 2012 at 10:19 AM, [hidden email] <[hidden email]> wrote:
Hi,

I think Matthew's proposal is pretty much aligned to what I would envision as a Form solution.
A basic form would be then decoupled into 2 classes at minimum, one responsible for fields/subforms inclusions and the other as serialization/unserialization.
Example:

namespace MyModule\Form\Model;

use Zend\Validator\Constraints as Validate,
    Zend\Filter\Rules as Filter;

use MyModule\Validator\Constraints as CustomValidate;

class LoginFormModel
{
    /**
     * @Validate\NotBlank
     * @Validate\Email(checkMx=true)
     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     * @Filter\Trim
     *
     * @var string
     */
    protected $email;

    /**
     * @Validate\Length(minLength=6, maxLength=25)
     * @CustomValidate\Password()
     *
     * @Filter\StripNewLines
     * @Filter\StripTags
     *
     * @var string
     */
    protected $password;

    // getters and setters here
}

namespace MyModule\Form\Type;

use Zend\Form\FormType,
    Zend\Form\FormBuilder;

class LoginFormType extends FormType
{
    public function buildForm(FormBuilder $builder)
    {
        // Prototype: $builder->add($field, $type, $options);
        $builder->add('email');
        $builder->add('password', 'password');
    }

    public function getName()
    {
        // Allows Form Service to retrieve instance of LoginFormType by doing: $formService->getForm('login-form')
        return 'login-form';
    }

    public function getOptions()
    {
        return array(
            'modelClass' => 'LoginFormModel'
        );
    }
}

// Processing

$loginFormType = $formService->getForm('login-form');
$loginFormType->setModel(new LoginFormModel()); // Optional. Allows update by assigning a pre-built instance
$loginFormType->bind($this->getRequest());

if ($loginFormType->isValid()) {
    // do stuff...
}


// View

<?php echo $this->form($loginFormType); ?>

You could also fill with some default information, by assigning a FormModel instance via setModel with some content to FormType.



Cheers,


On Wed, Feb 22, 2012 at 5:49 AM, Raphael de Almeida <[hidden email]> wrote:
> I think we could use an anonymous function here
>
>> <?php
>> $f = new StdClass();
>> $f->action = "index.php";
>> $f->method = "post";
>> function form($form, $fun_call){
>>   echo "<form action='$form->action' method='$form->method' >";
>>   $fun_call();
>>   echo "</form>";
>> }
>> form($f, function(){?>
>>   <intup type="text" />
>> <?});
>
>
>
>
> --
> []ão,
>
> Raphael de Almeida
>
> http://raphaeldealmeida.net
> http://www.twitter.com/raph_almeida
> http://rubyonrio.org | http://phprio.org | http://androidinrio.com.br  http://www.arduinrio.cc | http://dojorio.org



--
Guilherme Blanco
MSN: [hidden email]
GTalk: guilhermeblanco
Toronto - ON/Canada






--
Guilherme Blanco
MSN: [hidden email]
GTalk: guilhermeblanco
Toronto - ON/Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

Marian Meres-2
In reply to this post by weierophinney
Hi Matthew,

> I've just put the first draft of the Forms RFC in place:
>
>    http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms

I'm an end user (since early ZF1 versions), but I follow you guys on
this list (zf-contributors) with great attention. If I may, I'd have
one comment on the Forms. The SubForms...

ZF1 manual says there are intended for:
a) Creating logical element groups
b) Creating multi-page forms
c) Display groupings

IMHO, the name "SubForm" invokes completely different meaning. Where
in my opinion name "ElementGroup" (or similar) for a) would be more
accurate, b) should IMHO be removed completely (I see it as a
different concern) and c) is a view helper for the a).

Just my thoughts...

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

Re: Forms RFC now up

weierophinney
Administrator
-- Marian Meres <[hidden email]> wrote
(on Monday, 27 February 2012, 02:24 PM +0100):

> > I've just put the first draft of the Forms RFC in place:
> >
> >    http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms
>
> I'm an end user (since early ZF1 versions), but I follow you guys on
> this list (zf-contributors) with great attention. If I may, I'd have
> one comment on the Forms. The SubForms...
>
> ZF1 manual says there are intended for:
> a) Creating logical element groups
> b) Creating multi-page forms
> c) Display groupings
>
> IMHO, the name "SubForm" invokes completely different meaning. Where
> in my opinion name "ElementGroup" (or similar) for a) would be more
> accurate, b) should IMHO be removed completely (I see it as a
> different concern) and c) is a view helper for the a).

Excellent feedback, 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 RFC now up

Artur Bodera
On Mon, Feb 27, 2012 at 4:12 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
Excellent feedback, thanks!

btw: Have you heard of a "Fieldset"  ? :-)

About multi-stage forms, I believe these could be implemented in a Zfc module. That is because handling those requires a mixture of action controller magic, decorators, possibly rendering strategies and a good way of configuring the whole thing. I'd imagine this could could evolve to an abstract controller, that the user would extend configuring the number of stages and the "state machine" for the process. State changes could actually be neatly tied together with business logic using EM :-)

Next, the module would work with Zend\Form to generate necessary forms and orchestrate the process.

Unless anyone thinks that there's a good reason for multi-stage form processing (AKA wizards/creators) to be part of zf2 ?

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




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

Re: Forms RFC now up

till-2
In reply to this post by weierophinney


On Wed, Feb 22, 2012 at 5:10 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
I've just put the first draft of the Forms RFC in place:

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


I see decoraters are gonna move to the view layer – doesn't that sort of imply more tight coupeling? I don't want to start a flamewar, just wanted to ask for feedback.

Also, I realize this is an RFC but are decoraters gonna change fundamentally or is there gonna be an upgrade path (sort of/roughly)? I don't mind multiple ways but decorators are pretty nice once you get them.

I'm asking because it took me a while to wrap my head around decorators and I was wondering if this is basically knowledge I can throw away or if there is something similar in ZF2 at all. I wouldn't mind if decorators stayed around.

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

Re: Forms RFC now up

SpiffyJr
In reply to this post by guilhermeblanco@gmail.com
My responses are inline. Thanks for taking the time to reply!
 
The first item to modify is how you bind information to form. My original idea was bind($request), but this doesn't seem enough. Sometimes, you may want to bind extra information, so I think we need to decouple the bind into 2 methods: bindRequest and bindData. The first one binds exclusively the request (and not only post() as per your example), because there may have also arguments that come from query string. The second is an internal call from bindRequest after some internal processment, which allows to bind calculated information, for example, default values by a specific page. Does this make any sense to you?

The post() binding in the example wasn't intended to be taken literally. The bind() method should be able to accept an array or even any Traversable and handle it appropriately. I don't really like the idea of multiple bind methods because it makes things confusing. Binding data should be straight forward - anything passed to "bind" goes directly to the data object.
 

The second item to modify is how the elements are built. Leaving everything to the FormModel is not good, specially because you may want to reuse this Model under different perspectives. Let's make a simple example:
Suppose I want to map my FormModel into actually an Entity. I could have a page that only allows User to modify his email for example. If you map the Form elements into the User entity, how can you make this form available, that only displays the input type="email" field?
That's why you need the FormType to map specific functionality into FormModel. I'd call it group, interest or intention. Then, you could map different groups into FormModel, which could act with a single mapping to multiple FormTypes. Also, non-grouped validation rules are globally applied. Your FormTypes are actually your form elements mappings, including sub-forms inclusions.
Let me try to put into a real world example:


I like this idea. It allows you to customize validation rules for specific fields/elements of the data object. I think we'll need a better word for it - validation_group seems appropriate (ZF2 convention is underscore parameters).
 
The third change is consistency of methods. When you set the FormModel, you use the $formType->setModel(). It would be consistent to grab the FormModel by using $formType->getModel().

I didn't use setModel() anywhere but setters/getters for the data object (I'm calling it a data object, model works as well) are a given.
 

The fourth change is about unique responsibilities. Passing the $formType to view for rendering is far from ideal, specially because you would be including rendering logic on a class that was supposed to only deal with form elements mapping (not rendering). Ideally, you delegate this rendering responsibility to an auxiliar class, like a FormRenderer or FormView, whatever you want to name it. This class would then know how to render the form.
Inside of Controller, you just $formType->createView() or $formType->createRenderer().

I thought the idea was for view helpers to do the rendering of a form.


Does this makes sense to you?

My only closing thought is that I dislike the name "Type" and prefer "Definition" because it's more descriptive of its purpose.

Kyle S
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare 
Kyle S
blogs @ www.spiffyjr.me
github @ www.github.com/spiffyjr
follow @ www.twitter.com/spiffyjr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

guilhermeblanco@gmail.com
Hi Kyle,

Comments inline

On Mon, Feb 27, 2012 at 10:42 AM, Kyle S <[hidden email]> wrote:
My responses are inline. Thanks for taking the time to reply!
 
The first item to modify is how you bind information to form. My original idea was bind($request), but this doesn't seem enough. Sometimes, you may want to bind extra information, so I think we need to decouple the bind into 2 methods: bindRequest and bindData. The first one binds exclusively the request (and not only post() as per your example), because there may have also arguments that come from query string. The second is an internal call from bindRequest after some internal processment, which allows to bind calculated information, for example, default values by a specific page. Does this make any sense to you?

The post() binding in the example wasn't intended to be taken literally. The bind() method should be able to accept an array or even any Traversable and handle it appropriately. I don't really like the idea of multiple bind methods because it makes things confusing. Binding data should be straight forward - anything passed to "bind" goes directly to the data object.
 

As long we still allow to be either used with array or request, containing mixed querystring and post parameters, I'm fine with any change.
 

The second item to modify is how the elements are built. Leaving everything to the FormModel is not good, specially because you may want to reuse this Model under different perspectives. Let's make a simple example:
Suppose I want to map my FormModel into actually an Entity. I could have a page that only allows User to modify his email for example. If you map the Form elements into the User entity, how can you make this form available, that only displays the input type="email" field?
That's why you need the FormType to map specific functionality into FormModel. I'd call it group, interest or intention. Then, you could map different groups into FormModel, which could act with a single mapping to multiple FormTypes. Also, non-grouped validation rules are globally applied. Your FormTypes are actually your form elements mappings, including sub-forms inclusions.
Let me try to put into a real world example:


I like this idea. It allows you to customize validation rules for specific fields/elements of the data object. I think we'll need a better word for it - validation_group seems appropriate (ZF2 convention is underscore parameters).
 

There you go, validation_group! =)
 
The third change is consistency of methods. When you set the FormModel, you use the $formType->setModel(). It would be consistent to grab the FormModel by using $formType->getModel().

I didn't use setModel() anywhere but setters/getters for the data object (I'm calling it a data object, model works as well) are a given.
 

The setModel()/getModel() is used to either define FormModel instances or to retrieve populated instances after binding.
For consistency, I named as Model for FormModel compatibility, but you could also map the FormModel as Entity Models (both ORM or ODM or ZF2 DTO ones).
 

The fourth change is about unique responsibilities. Passing the $formType to view for rendering is far from ideal, specially because you would be including rendering logic on a class that was supposed to only deal with form elements mapping (not rendering). Ideally, you delegate this rendering responsibility to an auxiliar class, like a FormRenderer or FormView, whatever you want to name it. This class would then know how to render the form.
Inside of Controller, you just $formType->createView() or $formType->createRenderer().

I thought the idea was for view helpers to do the rendering of a form.
 

It still is. But how each item is going to recognize what and how it needs to be printed is a task of FormView.
The View Helper just print/gorup individual sets of items from FormView and render using the assigned Decorators. This means the decorators are part of FormView, and not View Helpers.

I can foresee some view helpers: form, form_errors, form_element, form_element_label, form_element_field, form_element_error

How they are going to know what should be rendered and with which decorator is a task of FormView, not the Form View Helper.



Does this makes sense to you?

My only closing thought is that I dislike the name "Type" and prefer "Definition" because it's more descriptive of its purpose.

Sure, FormDefinition is actually better, ya.
 

Kyle S
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare 



--
Guilherme Blanco
MSN: [hidden email]
GTalk: guilhermeblanco
Toronto - ON/Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

Stewart Lord
In reply to this post by weierophinney
Hi Folks,

Are we using annotations anywhere else in ZF2? Will there be an
alternative to annotations?

Thanks,
Stew


On 12-02-21 8:10 PM, Matthew Weier O'Phinney wrote:
> I've just put the first draft of the Forms RFC in place:
>
>      http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms
>
> We'll have an initial discussion on it during the IRC meeting Wednesday
> at 18:00 UTC (that's likely _today_ for anywhere but parts of the US as
> I write this).
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Forms RFC now up

weierophinney
Administrator
In reply to this post by till-2
-- till <[hidden email]> wrote
(on Monday, 27 February 2012, 04:22 PM +0100):

> On Wed, Feb 22, 2012 at 5:10 AM, Matthew Weier O'Phinney <[hidden email]>
> wrote:
>
>     I've just put the first draft of the Forms RFC in place:
>
>        http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms
>
>
>
> I see decoraters are gonna move to the view layer – doesn't that sort of imply
> more tight coupeling? I don't want to start a flamewar, just wanted to ask for
> feedback.

It's more like a bridge -- the helpers consume Form\* objects in order
to create output. One question I have at this point is if these helpers
should be in the Form component instead of the View\Helper subcomponent,
for precisely the reason you ask (though it then creates a coupling
to View by the Form component).

> Also, I realize this is an RFC but are decoraters gonna change
> fundamentally or is there gonna be an upgrade path (sort of/roughly)?
> I don't mind multiple ways but decorators are pretty nice once you get
> them.
>
> I'm asking because it took me a while to wrap my head around
> decorators and I was wondering if this is basically knowledge I can
> throw away or if there is something similar in ZF2 at all. I wouldn't
> mind if decorators stayed around.

TBH, I think "decoration" will actually be easier to achieve using the
helpers. The "WrappedElement" helper from the RFC is a good example:

    namespace My\Helper;
   
    use Zend\Form\ElementInterface,
        Zend\View\Helper\AbstractHelper;
   
    class WrappedElement extends AbstractHelper
    {
        public function __invoke(ElementInterface $element, $type = 'text', $class = 'element')
        {
            $view   = $this->getView();
            $broker = $view->broker();
            $input  = $broker->load('form_' . $type);
            $label  = $broker->load('form_label');
            $errors = $broker->load('form_errors');
            return sprintf(
                "<div class=\"%s\">\n%s\n%s\n%s\n</div>",
                $view->escape($class),
                $label($element),
                $input($element),
                $errors($element)
            );
        }
    }

This is similar to doing the following in ZF1:

    'decorators' => array(
        'Label',
        array('ViewHelper', array('helper' => 'formText')),
        'Errors',
        array('HtmlTag', array('tag' => 'div', 'class' => 'element')),
    ),

The primary difference is that the view helper explicitly states in
programmatic terms what the decorators array states in abstract terms.

Other differences include:

 * Performance: the logic in the decorators required in order to
   aggregate content is a bit hairy.
 * Readability: Looking at the helper, it's pretty easy to determine
   exactly what the final output will look like
 * Re-usability: I can use a single helper and not have to remember the
   exact configuration sequence required to get that output.

I personally think the view helper approach makes the actual _act_ of
decoration a little easier to follow. Fundamentally, it's doing the
exact same thing -- but the code needs no explanation, while the old
decorators approach _did_. However, I think if you were familiar with
and comfortable with the old approach, the new approach should be very,
very easy to pick up as a result.

--
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 now up

weierophinney
Administrator
In reply to this post by guilhermeblanco@gmail.com
-- [hidden email] <[hidden email]> wrote
(on Monday, 27 February 2012, 12:36 PM -0500):

> On Mon, Feb 27, 2012 at 10:42 AM, Kyle S <[hidden email]> wrote:
>         The fourth change is about unique responsibilities. Passing the
>         $formType to view for rendering is far from ideal, specially because
>         you would be including rendering logic on a class that was supposed to
>         only deal with form elements mapping (not rendering). Ideally, you
>         delegate this rendering responsibility to an auxiliar class, like a
>         FormRenderer or FormView, whatever you want to name it. This class
>         would then know how to render the form.
>         Inside of Controller, you just $formType->createView() or $formType->
>         createRenderer().
>
>     I thought the idea was for view helpers to do the rendering of a form.
>
> It still is. But how each item is going to recognize what and how it
> needs to be printed is a task of FormView.  The View Helper just
> print/gorup individual sets of items from FormView and render using
> the assigned Decorators. This means the decorators are part of
> FormView, and not View Helpers.
>
> I can foresee some view helpers: form, form_errors, form_element,
> form_element_label, form_element_field, form_element_error
>
> How they are going to know what should be rendered and with which
> decorator is a task of FormView, not the Form View Helper.

Umm... I never proposed a "FormView". I proposed, in the RFC, that we
move rendering to the appropriate location -- the view layer -- and
proposed we pass the various form objects (elements, groups, what have
you) individually to view helpers in order to create markup.

Thus, "decoration" would occur in the view helpers, typically by having
a helper that aggregates output from several helpers (potentially
contributing additional markup). The specific example I provided in the
RFC is of the "WrappedElement" view helper.

In your paragraph above, you indicate you think this makes for unclear
responsibilities. However, the idea here is that the elements and
whatnot are basically value objects, and the helpers are simply pulling
information from them in order to create markup. I'm unclear how this is
an unclear separation of responsibilities, to be honest.

Could you please elaborate on your ideas? I'm curious if they differ
that much from what I propose in the RFC, or how people want to interact
with forms at the view level.

--
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 now up

weierophinney
Administrator
In reply to this post by Stewart Lord
-- Stewart Lord <[hidden email]> wrote
(on Monday, 27 February 2012, 09:40 AM -0800):
> Are we using annotations anywhere else in ZF2? Will there be an
> alternative to annotations?

Annotations would be entirely optional -- it's simply a possiblity
enabled by the changes in architecture.

We have a similar situation with the Di component -- you _can_ use
annotations, but you're not forced to. It's completely opt-in.

And keep in mind: anything that you can do with annotations, you can
also do programmatically. They do not provide functionality you can't
already utilize.

> On 12-02-21 8:10 PM, Matthew Weier O'Phinney wrote:
> >I've just put the first draft of the Forms RFC in place:
> >
> >     http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms
> >
> >We'll have an initial discussion on it during the IRC meeting Wednesday
> >at 18:00 UTC (that's likely _today_ for anywhere but parts of the US as
> >I write this).

--
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
123
Loading...