Zend_Forms: What do you think??

[dele454]

Hi,

I just started my journey into learning the Zend Framework - i must say it is quite an interesting framework and am loving it all the way. But that springs one concern to surface regarding the Zend_Form Component:

I totally think the way of creating web forms and form elements the 'object' way is quite cool but it leaves me with two concerns or rather questions:

1. Instantiating the form object and creating form elements seems to eliminate or blur the role of the view layer.

2. Isnt this component mixing presentation logic with the Business logic?

3. Won't this route stifle the role of a web designer?

I would like to know what your comments are regarding these...

[DangerMouse1981]

1. Instantiating the form object and creating form elements seems to eliminate or blur the role of the view layer.

2. Isnt this component mixing presentation logic with the Business logic?

I've started using Zend_Form recently and have considered both of these points and whilst on the surface I believe they're accurate observations ZF seems to offer enough flexibility to get around them.

Whilst the presentation config is held within the Form model, there is no reason why these settings can't be made from a View layer thus preserving the seperation of responsibilties to an extent. Additionally generation of the HTML for form elements is conducted by decorators and view helpers so the actual presentation code itself is seperated.

3. Won't this route stifle the role of a web designer?

I'm not sure creating semantic markup is the same as design, the 'design' element, particularly relating to forms relates to their layout, this is still managed through CSS.

DM

[dele454]

Interesting response...

[dele454]

I have no doubt that the ZF is a solid framework I was left confused and wondering putting the MVC pattern into perspective in line with the Zend_Form Component.

Since all the form elements are being created using the Zend_Form, does it mean in the future for extensibility, if i need to add more from elements to the mix, i have do dive into the business logic just to add some few buttons or textfields???

[DangerMouse1981]

I have no doubt that the ZF is a solid framework I was left confused and wondering putting the MVC pattern into perspective.

Yeah I agree, I've been having the same difficulty e.g. ZF encourages you to assign models as properties to the View object from the controller.

Plus on reflection what I just said about updating settings relating to decorators from the View with Zend_Form kind of violates the idea that a View should have read only access to the model layer? Makes my head hurt puzzling through trying to apply MVC to a web context.

DM

[ctx2002]

I am not use Zend_Form , i did not like it, so i coded my own Form module.
i do not like to generate HTML element through PHP code.

If Zend framework is a visual framework, like MS's Visual Studio. under this context Zend_Form design probably make sense, since the Visual framework force Programmer to use drag and drop component.

[dele454]

After looking closely at my requirements and what Zend_Form offers, I dont think i will be implementing my forms using this component. Just like you said i totally agree: i dont want to handle my forms using form objects. So i will be skipping the application of Zend_Form!

Thanks for your take though

[digiscape]

3. Won't this route stifle the role of a web designer?

There is a solution to this on the way
framework.zend.com/issues/browse/ZF-3217

[phpimpact]

I've only used it in personal projects, and to be honest, I don't know if I'm going to use it again. It's a very complex component, you need to remember all the methods, filters, validators, decorators, etc. In my opinion it adds extra complexity to the application and it doesn't save you much time.

At work I never use it because of the following reasons:

- Front-end developers have to modify php classes, and we don't allow that. They can only access html files.
- It costs us more money to get a programmer to re-design a form than to get a junior front-end developer to change the html.
- We do not generate html forms, links or anything within our controllers:

$link = new Anchor('SitePoint');
$link->setHref('www.sitepoint.com');
$link->setTarget('blank');
$link->render(); 

What's the real advantage of doing that? Anyway, if you use Zend_Form, check out my latest post: Zend_Form Performance Issues

[Teeej]

I have no doubt that the ZF is a solid framework I was left confused and wondering putting the MVC pattern into perspective in line with the Zend_Form Component.

Since all the form elements are being created using the Zend_Form, does it mean in the future for extensibility, if i need to add more from elements to the mix, i have do dive into the business logic just to add some few buttons or textfields???

Have you ever added a field to a form and not had to edit the business logic?

If you have then the field you added to the form was totally redundant since you won't be doing anything with the data.

That said, Zend_Form is totally overkill. Web Development is inherently simple despite the best attempts of so many people to make it complicated.

[BerislavLopac]

Have you ever added a field to a form and not had to edit the business logic?

Personally, many times. I have in place a number of utilities for dealing with form data which makes handling it pretty automatic. One example is a script which takes all the fields from a form input, formats the data and emails it; exceptions can be set, but if a newly added field isn't an exception nothing has to be done. Another example is the ActiveRecord I use when dealing with databases; if there is a new field in the DB and it doesn't need any special handling in the application (e.g. somebody's phone number rarely needs anything but being displayed), all it takes is to add the field in the form.

[Teeej]

Would that not require mapping $_POST to the columns in your database automatically? That is so insecure that it's not worth talking about.

[cuberoot]

Depends on your form library. For instance, you could have well defined types like smallint, int, text, textarea, etc., which you can automatically filter to a reasonable extent. In addition to that, you can use prepared statements, which pretty much eliminate any SQL injection worries.

[Teeej]

SQL injection is too advanced for the kind of exploit that could happen there.

Imagine a table like this:

TABLE users,

user_id int,
full_name varchar,
password varchar,
display_name varchar,
email varchar,
status enum ('Administrator', 'Moderator', 'User', 'Banned')

Let's assume you have a well defined validation class for each column in the DB. And that you have a "settings" page where a user can change his or her password, etc.

<form action="script.php" method="post">
<input type="text" name="display_name">
<input type="text" name="email_name">
<input type="submit" value="save">
</form>

The exploit is injecting this:

<input type="text" value="Administrator" name="status">

Into the form with Firebug or by creating my own HTML file with a custom form.

In most web applications this wouldn't work because the business logic powering the form knows exactly what parameters to expect from a form or only updates specific columns, the downside is any new fields added to the form requires this business logic to be updated. But an ActiveRecord solution that AUTOMATICALLY picks up any new fields would take anything the user added and automatically update the database.

Not exactly brilliant.

[chestertondevelopment]

I quite like the way Zend_Form works in general and I know a lot of effort has been put into it but I hate the way it generates all of the code to display a form. Why can't you just call

echo $form->render('nameoffieldhere'); 

and write the table/list that displays the data yourself? Or even better (I think), the way I do it:

$form->render(new Textbox('fieldhere')); 

I have classes for all the different elements which all adhere to an interface and are in charge of rendering themselves.

I know there are ways to change the code Zend_Form generates but when working with template designers it just makes it more difficult and it feels counter-intuitive.

[BerislavLopac]

Would that not require mapping $_POST to the columns in your database automatically? That is so insecure that it's not worth talking about.

No, that requires mapping $_POST variables directly to the attributes of the objects. The database is isolated through at leas one further layer (ActiveRecord object), or in my case three further layers (the database abstraction layer, the ActiveRecord built on top of it, and my custom Model class which is using it as a storage mechanism).

[BerislavLopac]

SQL injection is too advanced for the kind of exploit that could happen there.

Imagine a table like this:

TABLE users,

user_id int,
full_name varchar,
password varchar,
display_name varchar,
email varchar,
status enum ('Administrator', 'Moderator', 'User', 'Banned')

Let's assume you have a well defined validation class for each column in the DB. And that you have a "settings" page where a user can change his or her password, etc.

<form action="script.php" method="post">
<input type="text" name="display_name">
<input type="text" name="email_name">
<input type="submit" value="save">
</form>

The exploit is injecting this:

<input type="text" value="Administrator" name="status">

Into the form with Firebug or by creating my own HTML file with a custom form.

In most web applications this wouldn't work because the business logic powering the form knows exactly what parameters to expect from a form or only updates specific columns, the downside is any new fields added to the form requires this business logic to be updated. But an ActiveRecord solution that AUTOMATICALLY picks up any new fields would take anything the user added and automatically update the database.

Not exactly brilliant.

Teeej, there are quite a lot of assumptions there. First, you need to know how precisely the user type field and values are defined. Second, I'd never use an enum field for that, relying instead on a properly normalized database with user type in a separate table. And third, when it comes to such sensitive data of course you'll have some program logic to sanitize it -- in my post above I was referring to more trivial uses.

[InFloW]

$link = new Anchor('SitePoint');
$link->setHref('www.sitepoint.com');
$link->setTarget('blank');
$link->render(); 

What's the real advantage of doing that? Anyway, if you use

I actually worked with a system that was built like that. I was told at the time it seemed like a logical way to control the way pages looked and keep consistent HTML.

Example of what it looked like:

$table = new Table();
$tr = new Tr();
$td = new Td();
$tr->addChild($td);
$table->addChild($tr); 

You defined everything like that so if you wanted a name it be $tr->name('fieldname');

It was like this for every single html component in existence and the ones there were not you derived with using the HTMLComponent class which all the others inherited.


The person who built it was long gone and it wasn't long and everything developed using this framework were gone. The system felt like the person did not like any html so it was a ton of wrappers to build html. Maybe came from a C++ background or even mainframe I did not ask. The system now just uses real html in views and the pages load a heck of a lot faster and development time has dramatically reduced.

[cuberoot]

That story reminds me of the complete and utter hell that is ExpressionEngine. Or at least was a few versions ago. Not only do they have a slew of those "helper" functions, but regular expressions also play a fundamental role in development. Ugh! I suffered immensely on that project.

[Teeej]

I actually worked with a system that was built like that. I was told at the time it seemed like a logical way to control the way pages looked and keep consistent HTML.

Example of what it looked like:

$table = new Table();
$tr = new Tr();
$td = new Td();
$tr->addChild($td);
$table->addChild($tr); 

You defined everything like that so if you wanted a name it be $tr->name('fieldname');

It was like this for every single html component in existence and the ones there were not you derived with using the HTMLComponent class which all the others inherited.


The person who built it was long gone and it wasn't long and everything developed using this framework were gone. The system felt like the person did not like any html so it was a ton of wrappers to build html. Maybe came from a C++ background or even mainframe I did not ask.

Probably came from a JavaScript background!

I'm sure we've all had to deal with code like this:

	var tbody = YAHOO.util.Dom.get('a_table');
	tbody.style.display = 'block';
	if ( tbody.firstChild.nodeName == 'TBODY' ) tbody = tbody.firstChild;

	var row = document.createElement( 'TR' );
	tbody.appendChild( row );
	row.id = 'scratchtr';

	cell = document.createElement ( 'TD' );
	row.appendChild( cell );

	var anc = document.createElement( 'A' );
	anc.className = 'remScratchDetails';
	anc.href = '';
	var img = document.createElement( 'IMG' );
	img.height = 8;
	img.width = 8;
	img.alt = 'Delete';
	img.title = 'Delete';
	img.src = '/images/x.gif';
	anc.appendChild( img );
	cell.appendChild( anc );

[BerislavLopac]

Probably came from a JavaScript background!

I'm sure we've all had to deal with code like this:

And what's wrong with this code? You must remember that PHP and Javascript operate in two very different contexts and are dealing with completely different output.

PHP is working on the server side and it's output basically nothing but formatted text ready to be interpreted by the browser. On the other hand, Javascript is operating within the browser and is working with browser's in-memory objects.

In other words, while I agree that this approach is unnatural for PHP or in general any server-side HTML "preprocessing" technology, it's only natural and logical for client-side Javascript.

[Teeej]

And what's wrong with this code?

I didn't say there was anything "wrong" with the code.

Do you just go around trying to bait people or something?


I wrote the code and I picked the example purely because innerHTML and other shortcuts don't work with tables. The point is that this approach to manipulating the DOM is an overly verbose and cumbersome method of writing something that we'd have been able to do in 2 seconds in a text editor. I brought up the code because whoever started writing these complex HTML classes might have worked this way and took some sort of joy in it.

The funny thing is that in JavaScript where working with the DOM in this way IS necessary, jQuery and other modern frameworks have exploded in popularity because they remove the need to work like this and allow you to do simple things like this:

$('#a_table').append('<tr><td><a href="#"><img src="/images/close.gif" width="8" height="8" /></a></td></tr>');

Whereas Zend Form and the code InFloW posted seem to be going in the opposite direction and making things more complicated and more cumbersome rather than simpler and faster.

Like I said earlier in the thread:

Web Development is inherently simple despite the best attempts of so many people to make it complicated.

[BerislavLopac]

Well, I understand your point. My opinion is that 90% of people -- even experienced Web developers -- are getting the whole thing very wrong anyway.

[BerislavLopac]

Well, I understand your point. My opinion is that 90% of people -- even experienced Web developers -- are getting the whole thing very wrong anyway.

[A_N]

Whereas Zend Form and the code InFloW posted seem to be going in the opposite direction and making things more complicated and more cumbersome rather than simpler and faster.

public function whateverNewAction()
{
  $form = $this->giveMeMyForm('new');
  if($this->_request->isPost())
  {
     if($form->isValid($this->_request())
     {
        $userSubmitedData = $form->getValues();
        // do what you want with clean, filtered data
        // redirect
     }
     $form->populate($this->_request);
  }

  $this->view->assign('form', $form);
}

public function whateverEditAction()
{
    $id = (int)$this->_request->getParam('id');
    $whateverData = WhateverDataModel::giveMeDataByPrimaryKey($id);
    if(!$whateverData) $this->_helper->getHelper('redirector')->goto('404Action');

    $form = $this->giveMeMyForm('edit/'.$id, true);
    if($this->_request->isPost())
    {
        if($form->isValid($this->_request))
        {
             $updatedData = $form->getValues();
             // update the record;
             // redirect 
        }
        $form->populate($this->_request);
    }
    else $form->setDefaults($whateverData);
   
    $this->view->assign('form', $form);
}

protected function giveMeMyForm($action, $edit=false)
{
  $form = new Zend_Form();
  $form->setAction($action);
  
  $fieldOne = new Zend_Form_Element_*(array(...));
  $fieldOne->addValidator(new Zend_Validate_*);
  $fieldOne->addFilter(new Zend_Filter_*());
  // and so on

  $fieldTwo = new Zend_Form_Element_Select(array(...));
  $fieldTwoValues = StaticModel::giveMeDynamicValues();
  $fieldTwo->setMultiOptions($fieldTwoValues);
  $fieldTwo->setValidator(new Zend_Validate_InArray($fieldTwoValues));
  $fieldOne->addFilter(new Zend_Filter_*());
  // and so on

  $form->addElement($fieldOne);
  $form->addElement($fieldTwo);

  if($edit)
  {
      $fieldThree = new Zend_Form_Element_Checkbox(array(...));
      // and so on
      
     $form->addElement($fieldThree);
  }
  
  // adding submit button

  return $form;
} 

complicated? maybe, but: by defining form object - you define the structure and rules (form meta data, not html form itself) for data you want from user and this provides validation / filtering that is transparent to you.

but keeping related data in separate places is really a better solution, isn't it?