In a new post to his blog today Rob Allen shows you how to create compound form element handling in a Zend Framework application thanks to some custom work with Zend_Form and Zend_View extensions.

A little bit of googling found this site http://codecaine.co.za/posts/compound-elements-with-zend-form which has not unfortunately disappeared, so the code in this article owes a lot of the author of that article. It turns out to be remarkably simple to create a single Zend Form element that is rendered as multiple form elements. We create an element object and a view helper object and we're done.

He shows how to create a custom form date helper that extends the base XHTML to create the isValid/getValue methods for handling the complex date input. There's also the code for the view that creates the custom date input and repopulates the content if there's a need.

Paul Jones points out a paper from Richard Cook, How Complex Systems Fail [pdf], and mentions how a lot of the points can directly correlate with programming in general.

The paper How Complex Systems Fail by Richard Cook should be required reading for anyone in programming or operations. Hell, it should be required reading for most everyone. You should read the whole paper (it's very short at under five pages).

He lists out some of the key points made in the paper including that complex systems can both be helped and harmed by the inclusion of humans in the mix and that, when things change, it opens the door for a whole new kind of failure.

New on Developer.com today there's a tutorial looking at creating complex, secure forms with the HTML_QuicForm2 PEAR package. This package will give you more control over the form, the validation it performs and the overall security it automatically handles.

For PHP developers, HTML_QuickForm2 PEAR package provides a programmatic interface for rigorously defining form controls, value requirements, and user notifications. Using HTML_QuickForm2 helps these developers create usable and secure Web forms without sacrificing visual appeal. This solution takes much of the guesswork out of secure forms development, allowing you to create robust forms with minimal time investment. In this article, I show you how to take advantage of HTML_QuickForm2 to streamline the creation and validation of complex HTML forms.

They help you get the package installed (if all goes well, it's just a call with the "pear" command-line tool) and how to create a simple form for accepting a user's name and email address. They modify it a bit to create another example - one that takes in a preferred format for the email that would be sent over to the user. They also work in the concept of required fields and how to show the error messages that might result from those being empty.

Jim Plush has taken a look at his models in the Zend Framework and has rethought them a bit to work with a bit more complex process than the usual simple sort of Zend Framework application.

The current active record/table gateway patterns just aren't going to cut it for the complex business logic that's approaching. I'm starting to lean towards the domain model approach which would increase the initial complexity of the design but allow for the flexibility for future changes and features. The issue is with where to put your business logic?

He diagrams out his potential solution and includes two bits of code showing how it would work in practice. He's soliciting opinions as to the validity of this approach too, wondering if its the best way to go for more complex application structures requiring these sorts of business requirements.

If your code is getting more and more complex all the time and you find yourself creating a similar group of objects over and over, you might check out Jani Hartikainen's latest advice and create a "builder" around them.

Sometimes if you have a complex class, which needs to be set up in a specific way: Perhaps it takes a lot of constructor arguments, or often requires calling some setters. [...] Sometimes if you have a complex class, which needs to be set up in a specific way: Perhaps it takes a lot of constructor arguments, or often requires calling some setters.

His example is a "message builder" wrapper that lets you specify the receiver, sender and message and inject them into a to() method call (with a fluent interface). He shows how to make sure that the object you need (the message object) is always complete.

On the PHP::Impact blog Federico Cargnelutti has expressed his opinion about the inclusion of the "GOTO" statement into future builds of PHP:

The GOTO statement has been the target of much continued criticism and debate, with the primary negative claim being that use of GOTO results in unreadable and generally unmaintainable spaghetti code. [...] Well, great news. The GOTO statement has just been added to the PHP language and it's now in the hands of experienced programmers and inexperienced Web developers.

He references a quote from Jeff Moore stating his dissatisfaction with the inclusion of it too. Comments on the post, however, correct Federico on how the "GOTO" in PHP will work - not quite as global as he'd thought.

In this new post Jani Hartikainen shows a quick and easy method for creating a custom form element in your Zend Framework application. His example is a custom time element.

The alternatives would be creating custom view helpers to output the custom form elements, and using the viewscript decorator. Creating a custom view helper would also require a custom form element class, and it would be a bit tricky. [...] I think the viewscript approach is the most flexible and simplest to implement, so I chose to go with that.

His example defines a time field made up of three drop down lists, one each for hours, minutes and seconds. Included is the code to make the element (including a regular expression for validation) and the view script to display it.

DevShed has the second of a two part tutorial posted today on sending emails with the included mail() function.

In this article we will look at the protocol that is involved in sending email messages. We will also examine the thorny issue of how to send an attachment with an email message. This article is the second of two parts.

They include examples of sending simple messages and more complex ones with things like attachments and custom headers. They also tack on a look at the PEAR::Mail package to the end showing how it can make sending some things a little less painful.

On his blog, Padraic Brady talks about the creation of custom web pages (in the Zend Framework) with the help of the Zend_View enhancements that have been introduced lately.

With the inclusion of Zend_View Enhanced as first documented, discussed and publicized in this blog series, in the Zend Framework as of 1.5.0 I'd like to thank everyone involved in the process. [...] The main problem of a complex View, is that the current Controller is only aware of a subset of its own required Model (data) and the current View. So how do do you get the View to include extra sections - for example, details from Technorati for your blog - which are common to ALL pages?

Normally, a call to _forward() would have been the norm, but this was more often overly complex for what the developer wanted to do. The new Composite View and View Helpers seem to be the remedy. They make it simpler to grab that information and pull it in without the need to make a whole other framework request to do so.

DevShed has posted part four of their series looking at the creation of graphics in PHP using the GD functionality. They take things a step further from the previous part and show how to create more complex shapes.

They show how to create things like:

• filled images and arcs
• filled polygons
• grabbing information the incoming image (like with the getimagesize function).