The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Zend_Forms: What do you think??

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?

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.

Originally Posted by dele454

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.

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???

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.

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!

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:

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.

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.

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.

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.

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).

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.

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:

PHP Code:

$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.

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.

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.

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.

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:

$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.