I don't know about you, but for me building HTML Forms and styling HTML Forms are maybe the most boring things in web development. It's repetitive and takes a lot of time to do things correctly. That's why tools like Twitter's Bootstrap and PEAR's HTML_QuickForm2 can help with this part of our job. Wouldn't it be nice to have QuickForm2 generate a markup compatible with Bootstrap CSS, so that you could get a nice looking form without to much efforts? Well, that's what I plan to do here.

He starts by creating a simple QuickForm2 form with no renderers attached (no pre-defined styles) and a custom render callback that wraps the items in "div" tags with the correct styles. There's also a custom renderer included for grouping items with additional styling attached.

However, not all is bad with Inheritance. When used properly it can be a great ally. The question that comes to mind is: how can you keep away from building derivatives that behave totally different from the chosen abstraction(s)? Here's exactly where the Liskov Substitution Principle (LSP) comes into play.

They choose to illustrate the principle in the form of a view renderer that, when an unintentional issue happens, throws a new exception. He creates the abstract class to generate the view objects and creates a few child objects that extend it. using these, he creates a set of templates that render a header/footer/body with the data given. The problem comes up when he tries to work with his objects and a partial view instead of a composite view is passed in.

It's a complicated situation to follow, but it does help make the principle a bit more clear. I'd suggest following it all the way through and possibly even trying out their code (included) to make it even more clear.

The PECL/Cairo library is pretty good at drawing vector graphics (in our opinion, as the developers, at least!), but one thing it's not able to do by itself is draw text with mildly advanced layout. [...] That's because the developers of the Cairo library decided to let another more specialised library handle the job of text layout.

Michael has created a wrapper for Pango in PHP (github) and some sample code that can be used as a test to ensure it's all setup and working. He steps through each part of the image creation and describes what's happening and what each method is doing along the way.

My thesis is that there's a gain in page rendering time when I disable automatic view rendering and use explicit render calls ($this->render('foo');) inside my controllers. And to cut to the chase, there is. On our app, I measured a 12% improvement using Xdebug's profiler - simple before-after-style.

He talks a bit about his setup for testing his theory complete with a customized loader as well as the platform (OS and web server) he ran the tests on. He used Xdebug to run the testing. His conclusion is a pretty obvious one - what you gain in convenience you sacrifice in performance.

Looking for some good looking graphs without having to pay for a library or resort to Flash graphs? Try creating your own using pChart. pChart is a PHP class oriented framework designed to create aliased charts. This project focuses on allowing developers to generate great looking graphs by increasing rendering quality introducing an aliasing algorithm.

It uses GD to create the graphs, so just about any PHP distribution out there will support it (if you're not sure, make a phpinfo() page to check out your setup). There's even some example graphs so you can get an idea of what some of the end results could be.

The reason for PhD to exist was that the previously used DSSSL based system was slow: a full build (all formats and all languages) took 24 hours to complete. Further, the tools the system based on were old, rusty and nobody understood why they broke on some machines, but also why they worked on other ones. Having a php-based system for PHP ensures that there is always someone around who can fix it if it's broken. This wasn't the case with the old documentation build system.

The conversion was spurred on by the fact that the PEAR documentation stopped building and more and more people were finding it hard to build on their machines too. He walks through the steps he took - installing PhD, converting over the docs to the DocBook 5 format and the first builds with the new system.

Now that at the XML was shiny, too, it was time to actually use PhD on it. The numbers were amazing: While a build for one format and one language took around 40 minutes on my system (dual core Macbook with 2GHz and 2GiB RAM), building the same with PhD takes 45 seconds!

Here was the hardest GSoC week ! I wrote a big part of the PDF output and both the themes "phppdf" (each PHP manual part in a file) and "phpbigpdf" (a big PDF file with all the sections).

Rudy's project for the GSoC is to create a Docbook renderer that can take in a standard Docbook file and output it into multiple formats. This past week saw the development of the PDF output method but he's also created methods for making a CHM (Windows help file) and a manpage output format. You can keep up with his latest progress on his blog.

When you render a Zend_Form, the elements will render to HTML compliance rather than XHTML compliance, even if you have < ?php echo $this->doctype('XHTML1_STRICT');?> at the top of your layout script. Practically, this means that all the input elements do not end in "/>". To resolve this, you need to call the doctype() view helper prior to rendering your form.

He includes an example of the doctype call (on a view object) to tell the script to output in the "XHTML1_TRANSITIONAL" format.

The PHP documentation team is pleased to announce the initial release of the new build system that generates the PHP Manual. Written in PHP, PhD ([PH]P based [D]ocBook renderer) builds are now available for viewing at docs.php.net. Everyone is encouraged to test and use this system so that bugs will be found and squashed.

Once the new build system is stable, expect additional changes to the PHP manual that will include an improved navigation system and styling for OOP documentation.

You can use the my.php page to set it as your default mirror if you'd like to use it seamlessly.

Most notably, I've started using the "new way" of using views, which is still undocumented in the manual. Rather than create a new Zend_View object, tell it where my views are, and echo a call to its render() method, I'm letting the controller's render() method do it all for me.

He illustrates with a simple example using the default framework directory setup, save for the special "scripts" directory he creates. This makes it possible for the controller to handle the rendering rather than the typical view functionality. Then, using the views is a simple init() call away, automagically.