Okay, I’m not the first to say this and I wont be the last, but Zend Framework’s documentation is not just terrible, but abysmally terrible, especially for newbies. The docs are disorganized, often times inaccurate for the current build version, and exhibit a serious lack of useful snippet examples. Zend could really learn a few lessons from the folks at CodeIgniter on how to write decent documentation. PHPDocs are not cutting it guys. Okay, enough of my ranting.

ZendTiger

I wanted to put together a pre-configured setup of Zend Framework that would give me some basic enterprise level administration of users, organizations, permissions and other baseline security features for some of my various projects. I’m calling it ZendTiger.

ZendTiger is a working configuration of Zend Framework 1.11.4 that uses fully autonomous modules and module-specific layouts while keeping the framework’s own internal default routing. The goal was to have self-configuring modules that just drop-in without having to configure any .ini files except what might be within the module itself. I also want to be able to add custom themes or “skins” to the application based on some variable within the layout which can be set automatically within the application itself. The final application also needs to be localized.

Getting Started

One of the first things you learn as a ZF newbie is that Zend does not work out of the box with modules and layouts. It just doesn’t self configure very well. Even with Zend Tool. You will spend not hours, but DAYS, trying to figure out how to get ZF to render pages using its default MVC while also using modules and layouts.

Fortunately, I have done some of the legwork here for you. After days of searching and learning and running into dead ends, I have finally pieced together a clean, working setup of ZF with modules and layouts humming along very nicely without all of the cruft of numerous plugins.

Modules

ZF deals with modules fairly well at this point but modules still have a way to go before they are seamlessly integrated within the framework. Some other ZF engineers have described modules as “second class citizens” of the framework and I am inclined to agree with this notion.

For instance, the Zend Tool CLI does NOT automatically setup modules properly for you. I had to fiddle with the application.ini and module bootstraps for some time before finally getting modules setup and working properly.

The goal of modules is (or should be) to allow for the dropping in of complete and isolated groups of functionality without affecting any other part of the application. This does not mean that modules cannot be dependent (use the functionality of) other modules, it just means that they need to be “drop-in-able” and you should not need to touch anything in the application configuration to make them work. Plug-and-play is the goal.

Also note that module bootstrapping can create a problem for some who are not aware of how modules work in ZF. ALL bootstrapping files are processed from all modules during the bootstrapping process, not just the active module’s. This is done on purpose because of possible module interdependencies, or one module needing the functionality of another module. If you build your bootstrapping without some kind of logic within your bootstrap files, you can easily have your modules overwriting the bootstrapping of other parts of your application. Keep this in mind when setting up your bootstrap files.

Layouts

Modules open the door to the desire to have different themes or skins for different modules of the application. Module-specific layouts is how this is achieved. However, once again, ZF doesn’t provide this configuration for your out of the box. Enabling Layouts using Zend Tool and then creating a module will not automatically add a /layouts folder to your newly created module. You have to do this by hand.

Once you initialize Zend Layout, there really isn’t an inherent way nor obvious way to configure ZF to use module-specific layouts. Many of the examples I looked at online of how to configure ZF to use layouts were either very complex for older versions of ZF, or the solutions just didn’t seem like the people writing them knew what they were doing in working WITH the framework. My coding philosophy is never work against the framework, work with the framework’s inherent ability whenever possible.

The simpler the code the better.

Most people want layouts to be set automatically based on the module being called. If a module has its own layout, we need to use that; if a module has no layout, use the default. This kind of logic for setting the layout automatically is best placed in a plugin at a point when the module name is known and the Zend Layout class has been instantiated. ZendTiger’s Layout plugin does this just after the routerShutdown event. This very early setting leaves open option of re-setting /overriding the layout within the controller if necessary, like with error message pages.

…

Conclusion

I’ve not posted a bunch of code snippets here at this point, just download the ZendTiger files and you’ll be up and running. ZendTiger expects your ZF library files to already be in your PHP path. If ZendTiger cannot find your ZF files, setup your environment so that PHP knows where your ZF library files live.

I’ll add more as I continue developing … I hope ZendTiger saves you a lot of time. Cheers!

Downloads

The following file is the latest working version of ZendTiger.

Download ZendTiger

Credits

I could not have gotten very far on this project without the help of the following people and their blogs:

Jeroen Keppens of Amazium
Leonard Dronkers of Sreknord

If WebTigers has helped you out, feel free to link to us!

____________________________

K. Beau Beauchamp is a professional UI developer with over 15 year’s experience in graphic design, marketing communications and object-oriented UI programming. Beau can be contacted via email here.

Ж

The UI, if it’s well engineered, can shine a light on how professional the rest of your team’s efforts have been. Likewise, a badly designed UI can cast a shadow over what might otherwise be a really great application.

But before we learn how to find a good UI professional, it makes sense to understand what UI is and how it fits into a truly professional product.

Understanding Professional UI

You can assemble a world class Java / Oracle team who just built the most amazing technology, but if your UI has been an after thought, bad UI can make all that high-end technology look like it was written by a bunch of amateurs.

Not Just Another Pretty Face

The days of being able to use your Java or .NET people to build UI are over, actually they were over years ago, but sometimes it takes time for the rest of the development world to catch up to the technical realities.

Today’s UI developers are highly skilled, multi-disciplined specialists trained and experienced to not just add nice graphics and code HTML, but functionally design and improve how the application “interacts” with the end-user.

Professional UI is more than just nice looking graphics.

I recently worked with an IT manager of a major US corporation who told me, “We need to put some serious lipstick on this.” The problem wasn’t really their graphics, it was their workflow that needed a serious update and reworking. No amount of “lipstick” I could come up with was going to fix a blatantly bad design. They had let their Java staff design how the application would behave and it caused some serious confusion for the end users.

Awesome UI Is Not The Easy Path

The problem is that your users don’t think like programmers, and programmers usually don’t spend a lot of time thinking about, “Now, how can I make this easier for others to use?” No, generally their thought is, “How can I make this easier for me to code.”

It’s this kind of situation that results in a poorly designed amateur UI.

Well designed UI is not always easy to code. It requires that you take the time to really think through the user experience and workflow, always asking the question: “Now, how would our users really like to see this work?” Sometimes a quick DHTML pop-up or slide-down form is what would make the user experience much more smooth; but it takes a bit more time to build these little Web 2.0 gems than it would be to “force” your user to a whole new page or code and ugly pop-up browser window.

First Things First

The basic problem with using back-end developers to build the front-end part of the application is that typically the back-end people can really only think like back-end developers, not end-users. The Java guy starts the application development process by building a database. That is exactly the wrong way to approach an application.

An application that will exhibit professional UI should always begin with the public interface development first. Whether you prefer to use wireframe documents or just rough-code some HTML pages out of the gate, these initial interfaces will be crucial in determining what functionality fires and when; and what, exactly, needs to ultimately get persisted in the database and in what tables.

Ultimately, building projects this way allows for much better documentation, it saves a lot of time and streamlines the effort for the back-end guys.

Super-Awesome Power At Your Fingertips

If you’ve been programming in UI for any length of time then you’re familiar with Javascript’s built-in getElementById function that is used to return a single element within the DOM tree by simply passing in the element’s ID. YUI’s getElementsBy is quite simply getElementById on some serious steroids. Not only does this powerful function allow you to snap-up a single element, but it can grab a whole array of elements chosen and filtered any way you like, all in a single call.

But wait, there’s more! getElementsBy also allows you to manipulate each of the elements within your array with an optional function you supply!

Setting-up Your Page to Use YUI

First you’ll need to download and copy the core YUI files to a directory on your site. I usually like to have a /javascrpt or /js folder inside my document root that holds all of my JavaScript files. The core YUI files you’ll need will be found inside the /yui/build directory. I like to copy YUI’s /build folder to my /javascript folder and rename /build to /yui for convenience.

Now add for following code inside the <head> ... </head> tags of your page:

or you can have your page load the YUI files directly from YAHOO! using this script tag instead of the one above:

Now you’ll have all of the various YUI Core, DOM and Events functions at your command. Let’s look at what the getElementsBy function params look like:

var Dom = YAHOO.util.Dom;
var els = Dom.getElementsBy(
    function(el){ ... },
        tagname,
        parentroot,
        function(el){ ... }
);

All of the YUI functions live in the YAHOO namespace. As such, I like to pair down my code by assigning all of the Dom and Event functions to a simple reference var, like Dom. This way, I can access the YUI DOM functions with a simple Dom.getElementsBy() as we see in line 2.

Note that getElementsBy can work with or without returning anything. If you do return elements, note that unlike getElementById, getElementsBy always returns an array() of elements. Even if you will only be returning a single element, keep in mind that it will be referenced as els[0].

Line 3 is where the real fun begins. You begin gathering your elements with a simple boolean function that returns true or false. Let’s say I want to toggle a check or uncheck for every checkbox within a form. A good boolean function to use here would be return (el.type == 'checkbox');. Notice that el is an element that will get passed into this function to be tested. If the element has the attribute of type="checkbox" the function will return true and add the element to our els array.

Notice that only the first attribute of getElementsBy is necessary. The second and third parameters can be set to null. However, setting these parameters to null will cause getElementsBy to process EVERY ELEMENT on the page! This is not very efficient, especially for really large pages. That’s where the second and third parameters of this function come in handy. In line 4 of our code we can specify a specific tag name, such as input. In this way, the getElementsBy function will ignore all elements except input elements which it will then pass to the boolean function we built in the previous paragraph.

Even with this optimization, you still might want to further define where to begin your elements search. getElmentsBy allows you to optionally specify a third parameter, a root parent element to search within. If all of the elements you need to process are the children of a specific div for instance, passing in the ID string or element reference of the containing parent will limit even further where within the DOM getElementsBy needs to look.

So, with these three parameters supplied to our getElmentsBy function, we can collect a very specific set of elements, in our sample case we’re looking for all of the checkboxes, anywhere within the DOM of our page.

Putting getElementsBy to Work

Here’s where getElmentsBy becomes a real time saver. Normally, once you have built your array, you’d need to write code that loops through each of the elements within your array to do something with each element of the array; in our case we’re setting the checkbox elements to either be checked or unchecked. So why not just apply whatever function to each element as it is being added to the array built by getElmentsBy? Brilliant!

The final param of the getElmentsBy function is designed to do just that. Using this optional function, we can apply code to each of the elements being added to our final array. And we’re not just limited to checking or un-checking chekcboxes here. Anything you can do inside a function can be applied to any, all or some of the array elements.

Use this final function to selectively add an event listener, set element values and/or attributes (which is what we’re going to do with our checkboxes), or whatever.

var Dom = YAHOO.util.Dom;
var els = Dom.getElementsBy(
    function(el){
        return ( el.type === 'checkbox' );
    },
    'input',
    'myform',
    function(el){
        el.checked === true;
    }
);

One Call Does It All

So let’s show a simple function using getElmentsBy that checks or un-checks all of the checkboxes on a form.

Here’s the example:

and here’s the code:

Click me
One
Two
Three
Four
Five
    

Copy and save the page as myfile.html to see how it works!

Conclusion

While other JavaScript libraries indeed have similar functions, I really like the inherent flexibility of getElementsBy. The beauty of YUI is that it works like JavaScript is supposed to work, it’s written they way JavaScript is written. And you don’t have to memorize a whole new syntax or funky var language to use the power of YUI.

____________________________

K. Beau Beauchamp is a professional UI developer with over 15 year’s experience in graphic design, marketing communications and object-oriented UI programming. Beau can be contacted via email here.

Ж