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.

Enterprise-class JavaScript

Here’s the scene: You’re the new project manager sitting at the conference table with the rest of the development team. You’ve just hired a new UI person to take the reins of your application’s front-end and deliver a product that will be a slick Web 2.0 production.

Mind you, the reason you hired a UI person in the first place is because your development team has been struggling with UI issues. The CSS is a mess, there are cross-browser display issues, and sometimes the DHTML works and sometimes it quits without warning. Your dev team has spent countless hours fumbling with these issues without a whole lot of success or the successes have come at a steep price in over-spent hours.

The discussion inevitably turns to the JavaScript and what is currently in-place within the application. Some of it is custom, some of it is jQuery, there’s an open-source piece here and purchased module for image display over there.

Okay, it’s a mess. You know it’s not working so you ask your UI pro for their input. The UI pro recommends a wholesale change in the JS library and a move to a full-stack framework. The rest of the dev team groans and begins to grumble. “Replace all this work!? Can’t you just fix what’s broken? That’s why we hired you!”

Your new UI pro simply replies, “I just fixed the problems. This is an enterprise-class application and it needs a robust framework to make the UI perform uniformly. You cannot piece these things together with scotch-tape and bubble gum. It’s all got to work together. Otherwise you end up with a mess of conflicting standards and multiple incompatible objects all trying to talk to each other through yet even more translation objects.”

“But we’re using a framework, jQuery!” the team lead insists.

Then your new UI pro drops a bombshell and says, “jQuery is not an enterprise-class framework.”

The room erupts into brash dissent from the developers who wrote the current UI. “Like hell it’s not! jQuery is the more widely used framework on the planet!”

Your UI pro allows the din to quiet. They’ve been down this road of discussion more often than they care to count, “jQuery is not the most widely used ‘framework’ on the planet, because it’s not a ‘framework’, it’s a library. Big difference.”

Clash of the Titans

The above scenario is one I have had to deal with on a number of occasions.

As a project manager you have a lot of things to manage with your project, one of the most important is what technologies will be implemented to build the application. If you have a Java or .NET shop, those decisions are easy for the backend, you use what your engineering staff know how to use.

But what do you do if your engineering staff doesn’t know what to use and really doesn’t know UI all that well? Guess? Use what’s popular?

More often than not when I come into a shop where a project is already underway, the backend team has chosen a JavaScript library for the front-end. Generally it’s jQuery. The question I ask is, “Why did you go with jQuery?” and the answer is always the same, “Everybody uses jQuery. It’s industry standard. It’s what we know.”

The last part is the true reason. “It’s what we know.” The unspoken reason is also, “jQuery is super easy and helps us speed through a lot of basic DHTML we don’t have a clue about how to write otherwise.”

One of my primary beefs with jQuery is that it hides the nuts and bolts of true JavaScript coding and forces you to code it’s way instead of in a natural object-oriented fashion the way JavaScript was designed to work. While jQuery’s syntax is fast and easy, it’s not really JavaScript, it’s a language called jQuery that’s built on top of JavaScript.

Why is that a big deal? Well for starters, I’ve worked with engineers who said they knew JavaScript but the reality was if you removed the jQuery library from the application, they were hopelessly lost.

jQuery was really the only “JavaScript” they knew how to write. Ouch.

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.

Ж