David Abdemoulaie couldn't find just what he was looking for when it came to a minification tool for his Javascript/CSS in his Zend Framework applications so he developed bundle-phu.

I've used a few different CSS/JS bundlers, but none have ever fulfilled all that I needed. [...] Thus, I created bundle-phu. Bundle-phu is a set of Zend Framework view helpers that do all of the above. Bundle-phu is inspired by, bundle-fu a Ruby on Rails equivalent. [...] It automagically concatenate, minify, and gzip your javascript and stylesheets into bundles. This reduces the number of HTTP requests to your servers as well as your bandwidth.

He includes how to install it, how to use it in your code and what the end result is when you view the actual HTML source. You can check out the latest version from the project's github account.

Rob Allen has a quick new post for you Zend Framework users out there on how to detect if a view helper even exists before you try to use it.

If you need to know whether a view helper exists before you call it, one way is to write a simple view helper to tell you. You can then use it in a view script.

The comments mention another way to do it - calling the getHelper method - but that can cause exceptions to be thrown if the helper doesn't exist. You can find more on view helpers in this section of the Zend Framework manual (or here on custom helpers).

In their final article in their "Introduction to CodeIgniter" series, DevShed has posted this look at how to create the views for their sample application. They'll output the user information pulled from a MySQL database.

In its current state, the structure of this sample application looked rather incomplete. It was comprised of a model and a controller class, where the first was responsible for retrieving user data from the table, and the second was charged with embedding this data in some view files, which actually haven't been defined yet. Therefore, in this final chapter of the series I'll be creating these views.

The new functionality they add into the application pushes an array of the user content into the "content" view. It loops through the records and outputs the first and last names as well as the user's email. Header and footer views are also included.

DevShed has posted the next article in their "Introduction to CodeIgniter" series today. This new tutorial, the sixth in the series, looks at reworking their example to use a model instead of a direct connection to the database.

You'll recall that I developed a sample PHP application. It displayed the contents of some database rows which were previously fetched from a "users" MySQL table. Moreover, these rows were retrieved by using the active record class bundled with CI. However, it's also possible to define a model that performs all of the database-related operations, instead of directly using the database class.

They create a simple User_model class that loads in the database functionality and, using that object, makes a select (get) to retrieve all user information in one method and select information in another. CodeIgniter "automagically" knows to pull from the Users table based on the naming convention of the file and class.

On DevShed today they continue their introduction to CodeIgniter series with this new tutorial looking at views nd how to move some of the presentation logic out of them an into a "sub-view container".

Manipulating views with CodeIgniter is a straightforward process. [...] However, CodeIgniter gives PHP programmers enough freedom to handle views in several useful ways, which can speed up the development of web applications. Therefore, if you're taking your first steps with CI and wish to learn some handy approaches that will help you work with views in a truly painless fashion, then start reading this tutorial now!

Their method defines a reusable view "container" (their content_view.php) to handle the looping that was previously just done in the one view for the user listing. This makes the content_view script reusable across more than one view and standardizes some of the look/feel in the view's output.

DevShed has posted the next in their "Introduction to CodeIgniter" series - this new tutorial about returning strings back from the views of your application.

Speaking more specifically, it's possible to feed the "$this->load->view()" method of CI a third Boolean parameter, to return the contents of a view to calling code after the view has been parsed. This is a handy variation of the method demonstrated in the previous article, and in this tutorial I'll be taking a close look at it, so you can grasp its underlying logic.

This technique could be useful when you want to render a certain block of code but don't want the application to have to reparse and rerender it. Pass the information to one view call, return the output back into a variable and push that back out into a main view any number of times.

DevShed takes another look at the CodeIgniter framework with this first part of a new series tackling view handling in the lightweight framework. Views are the final stop for the processed data, displaying any one of a multitude of types of data back out to the waiting client software.

In reality, implementing this view-centric method is actually pretty easy to achieve. However, CodeIgniter provides web developers with enough flexibility to handle views in all sort of clever ways. Therefore, in this series of articles I'll be discussing in detail some common approaches that you can use to generate views, ranging from loading them sequentially, to using more complex methods, such as including views within other views.

They introduce you to the view system CodeIgniter offers and show you how to create a basic view as a part of a controller class that displays a page with a header, user content and a footer.

Reflection can be a handy tool when you need it, but how many times have you actually found a use for it in the past few applications you've written? Jani Hartikainen has one suggestion of a place it can be used - form generation.

Most web applications use forms. Forms often represent some model, such as a news post. If the model is simple, writing the form in HTML is not too bad, or we might be able to use a scaffolding feature in our framework. [...] Here's a good use for reflection! Since in models we often have a naming scheme for the data the users would be able to input, we can utilize this knowledge with reflection to generate a list of possible fields in the model, and then generate the form with less typing required from us.

His example looks into the model class and pulls out the "get" functions and, after pulling out the name, adds it to a fields array. This array is then passed out to the display part of the script and looped over to create a text field for each. He expands it a bit to also include checking for "@return" values in docblock comments for the type of form field that should be displayed.

DevShed finishes off another series with the last part of their look at making a blog app with the help of the CodeIgniter framework.

By using the framework, you'll be taking advantage of the MVC pattern to separate the application's logic from its visual presentation. This article will focus on the improving the appearance of the application's final details: the section concerned with receiving and displaying comments.

Starting with the full source from the previous parts of the series, they modify the view file for their blog's comments to ass come nice CSS and styling. The final page shows the entire code for the application (split out ino chuncks of code for each file).

Chris Hartjes continues his series looking at converting over legacy applications into a CakePHP environment with this third part, a focus on what can be one of the hardest parts - separating out business logic and presentation logic.

Anyway, onto other matters. As you saw in parts 1 and 2, a bug part in having a successful transition from legacy app to CakePHP is having an environment that is well suited to the use of a framework. Having laid out the groundwork for that switchover, it's time to talk about the part of a refactoring or porting that is most difficult: separating your business logic from your display logic.

He talks about fat models, skinny controllers and flexible views with some code to illustrate each. This method makes the models do most of the work while the controllers are more of a go-between for them and the views. The views, then, are pliable enough to work with whatever data might be thrown at them.