In a new post Bertrand Mansion shows how he combined the versatility of the PEAR QuickForm2 package and the Bootstrap project from Twitter to quickly make a form using the project's styling (CSS).

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.

On DevShed today there's a new tutorial posted talking about the Liskov Substitution Principle (part of the SOLID set of principles) and how to use it in a practical example using some object-oriented PHP.

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.

Michael Maclean has a new article today talking about the Pango graphics library and how it can be coupled with the Cairo PECL extension to more easily create better looking text in dynamic images.

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.

In a new entry to his blog, Till Klampaeckel looks at view rendering for Zend Framework applications and how, as he assumed it would, making a change in the automatic rendering on the views could speed things up quite a bit.

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.

Vinu Thomas points out a nice looking PHP charting library on his blog today - pChart.

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.

Christian Weiske set out on a project - no small thing - to convert the current PEAR documentation info over to the PhD DocBook rendering system. In a new post he talks about the conversion process and some of the technology involved.

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!

Rudy Nappee has just finished what he calls the hardest week in his Google Summer of Code project - work on the PDF output methods:

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.

Rob Allen has posted a quick tip of how to use the Zend_Form component of the Zend Framework to correctly render XHTML compliant output.

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 main PHP website has announced the release of the new documentation build system (as Hannes Magnusson mentioned previously) is ready and has been launched for testing.

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.

In a new entry today, Ben Ramsey, how's been working with the Zend Framework for a bit now, shares an interesting bit of information about how to use Views a little bit differently.

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.