The jQuery UI widget factory provides a method to inherit one and only one widget. For example If you look at some of the jquery ui widget source code (draggable, droppable, sortable) you will notice that most inherit mouse. However when writing my own widgets I found that I never needed to do any of the things inheritance was intended for, such as overriding methods.

For me, I just needed some of the default widget behaviors (like sortable) applied to my own custom code. I decided to wrap the existing widget behavior rather than extend.

So how does this work? Let’s take the example of a page selector.

My hypothetical page selector widget needs to do the following:

• User can click to select a page
• User can reorder pages
• Selecting or Reordering triggers an ajax save
• I want to append the draggabe handle in the JS

As you can see there is a mix of behavior, the reordering is boiler plate sortable, but appending the draggable handle and other features are all custom.

A quick visual:

So for this widget I want to use sortable to handle the sorting, but everything else will be custom code.

Here is the base/empty code for our widget:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$(function(){
    $.widget("ui.pageSelector", {
        options: {
 
        },
 
        _create : function() {
 
       },
 
        _destroy : function() {
 
       }
 
     }); 
});

Options

Our first challenge are the options. We have two sets of options, the options for sortable and the options for pageSelector (our custom widget). You can handle options as either one object or two.

One Object

1
2
3
4
5
6
7
8
9
10
11
12

    $.widget("ui.pageSelector", {
        options: {
            customName : "customValue",
            items: '.sort-item',   
            handle:'.sort-handle',
            containment: '.page-slider-container',
            placeholder: 'sort-item-placeholder ui-state-highlight',
            forcePlaceholderSize: true,
            opacity:'0.6',
            revert:'100',
            delay:'100' 
        },

In the above example options for the wrapped widget and the custom widget are all together (customName is for the pageSelector widget). I think there are significant problems with this approach, for example when we instantiate sortable we pass it options it does not need, and I can imagine name conflicts (if you are not careful).

Two Objects

1
2
3
4
5
6
7
8
9
10
11
12
13
14

    $.widget("ui.pageSelector", {
        options: {
            customName : "customValue",
            sortableOptions: {
                items: '.sort-item',   
                handle:'.sort-handle',
                containment: '.page-slider-container',
                placeholder: 'sort-item-placeholder ui-state-highlight',
                forcePlaceholderSize: true,
                opacity:'0.6',
                revert:'100',
                delay:'100' 
            }
        },

I like the second approach better as we can handle the sortable options separately. Later when we invoke sortable we can pass just the options it needs.

Instantiating The Wrapped Widget

In the _create method we can now instantiate the sortable, passing in the sortableOptions object:

1
2
3
4

        _create : function() {
            var self = this, o = this.options, e = this.element;
 
            e.sortable(o.sortableOptions);

Hooking Into The Wrapped Widget

Now that our widget is instantiated we can start adding the widget specific behavior. In this example we want to trigger a save on the wrapped sortable’s event sortupdate. To do this we can bind that event in our _create method:

1
2
3
4
5
6
7
8

        _create : function() {
            var self = this, o = this.options, e = this.element;
 
            e.sortable(o.sortableOptions);
 
            e.bind("sortupdate",function(event,ui){
                self._saveSortOrder();
            })

You can also invoke methods on your sortable using this syntax:

1

e.sortable('serialize');

The above approach has worked really well for me and I was able to create custom widgets that encapsulated the behavior I needed.

Option Based Function Callbacks

Semi-related: I discovered that some “widgets” that you might want to wrap (say non jQuery UI like tinyMCE) allow callback functions to be defined as an option. This can cause problems if you want to invoke a function from within your widget.

For example

1
2
3
4
5
6
7
8
9

    $.widget("ui.pageSelector", {
        options: {
            customName : "customValue",
            someFooOptions: {
                save_callback : function () {
                 //I want to do something here!                     
                },                
            }
        },

In the above example I want the save behavior to be handled by my custom widget, but the code I am wrapping only provides a callback method. You can’t invoke widget methods from the options since there is no scope.

My solution was to use a trigger bound to this widgets instance:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

    $.widget("ui.pageSelector", {
        options: {
            customName : "customValue",
            someFooOptions: {
                save_callback : function (id) {
                    // Trigger Custom Event
                    $(id).trigger("my:customSaveEvent");                                       
                },                
            }
        }, 
 
 . . .
       _create : function() {
            var self = this, o = this.options, e = this.element;
 
            $(e).bind("my:customSaveEvent", function(){
               //do stuff           
            }),

In this example I trigger the “my:customSaveEvent” in the callback. This event is bound to behavior in my widget. For this to work you just need to somehow get the id of the widget passed in (or some other identifier). You want to be careful not to trigger the event on the entire document as you may have multiple widgets instantiated.

In the past I directly called methods from each widget, but this creates a lot of “glue code” and dependencies. I had recently watched this YUI Theatre video on Scalable Javascript Application Architecture and wanted to apply the following to my jQuery UI Widgets:

• Widgets should be able to live on their own
• Keep everything loosely coupled

Approach

Given the above I decided to use jQuery’s custom events to enable publish/speak and subscribe/listen into my widgets. Each widget would publish certain events and subscribe to others. This approach effectively decouples the widgets and allows them to function independently.

The two key jQuery methods:

• bind – Bind will perform the “listen” or “subscribe”
• trigger – Trigger will perform the “speak” or “publish”

Example Code Subscribe/Listen

Note I am using jQuery 1.4.2 & jQuery UI 1.8rc3.

The following is a bare bones widget and has most of the code removed so it can serve as an example. This widget has two bound custom events dpui:ajaxStart & dpui:ajaxEnd (DPUI is just my namespace for events “DevPatch UI”). Whenever the custom events are triggered the widget will output text to a firebug console.

UPDATED March 22, 2010
I updated my custom event format to namespace:eventName.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$(function(){
    $.widget("ui.ajaxStatus", {
        options: {
 
        }, 
        _create : function() {
            var self = this;                     
 
            self.element.addClass("dpui-widget")
 
            $(self.element).bind("dpui:ajaxStart", function(e) {
                console.log("ajax start");                                                 
            });
 
            $(self.element).bind("dpui:ajaxEnd", function(e) {
                console.log("ajax end");  
            });     
        },
        destroy: function(){
            $.Widget.prototype.destroy.apply(this, arguments);
        },                     
    });       
});

Example Code Speak/Publish

Below is the code that would be in another widget.

1

$(".dpui-widget").trigger("dpui:ajaxStart");

The class .dpui-widget is my namespace class that is applied to every UI widget with speak/listen. If you wanted to do this globally you could use:

1

$(document).trigger("dpui:ajaxStart");

Important to note here that I am not calling dpui:ajaxStart on the ajax widget, instead I am triggering this event on a sub-set of document objects. Any document objects that are subscribed to this custom event will have their action triggered.

Conclusion

I think the above approach solves many of my problems, but I can imagine some issues, especially on larger projects.

If you have additional thoughts or suggestions for a different approach please leave a comment.

The following two blog posts were very helpful and are a good intro to jQuery widgets and event pooling.

http://bililite.com/blog/understanding-jquery-ui-widgets-a-tutorial/

http://www.michaelhamrah.com/blog/2009/12/organizing-javascript-for-event-pooling-with-jquery/

For more ANT goodness check out my other posts: Deploying Drupal with ANT, CSS Cache Busting & Drupal, Using YUI Compressor with ANT.

Methodology

For my project I need ANT to do the following:

• Checkout From Subversion HEAD Or A Specific Revision Of The Project
• Remove Files That Should Not Go To Production (Documentation)
• Configure Zend For The Correct Environment
• Securely Transfer Code To Production Server

I think this is a very common use-case so… onto the code!

Pre-Reqs

• Apache ANT
• SnvAnt – Provides Subversion Interface To ANT
• JSCH Jars – Provides SCP To ANT

I am using Zend 1.10. In this example the only Zend dependency is using Zend_Application with production/development sections in your application.ini file.

Setup Zend

Setting up Zend is the easy part. We need a folder within our project to hold two files:

• build.xml – the file that contains all the ant tasks
• build.properties.prod – the file that contains the properities required by build.xml

We also need a .htaccess file that will be used in production. The important part of this file is APPLICATION_ENV, this value is used by Zend to determine what environment it is in and what settings to use from your application.ini file.

Simply copy the .htaccess file that is already there, and rename to htaccess.prod. Edit the file and change
SetEnv APPLICATION_ENV development to SetEnv APPLICATION_ENV production.

The below screenshot shows how I have set things up. Orange arrows are the important parts.

build.properties.prod

Below is my example properties file. Included are settings for:

• Locations of Subversion Jar Files
• Subversion Login Information
• Temp File Locations
• Path To Comment File
• Production Server Information (user/pwd are entered a runtime)

The path to the comment file is where we will instruct ANT to insert the version information and timestamp. This allows us to “view source” on the production site and see the revision information and date/time of last build.

You need to customize all values for your own environment, the comments within the file should help explain what you need to do.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

# -----------------------------------------------------------------------------
# build.properties
# This file is referenced by the  build.xml file.
# -----------------------------------------------------------------------------
 
# -----------------------------------------------------------------------------
# External jars needed for Subversion
# Example:
# lib.dir=/usr/local/ant/lib
# svnant.jar=${lib.dir}/svnant.jar
# svnClientAdapter.jar=${lib.dir}/svnClientAdapter.jar
# svnjavahl.jar=${lib.dir}/svnjavahl.jar
# -----------------------------------------------------------------------------
 
lib.dir=/usr/share/ant/lib
svnant.jar=${lib.dir}/svnant.jar
svnClientAdapter.jar=${lib.dir}/svnClientAdapter.jar
svnjavahl.jar=${lib.dir}/svnjavahl.jar
 
# -----------------------------------------------------------------------------
# Subversion Login and URL
# Example:
# svnant.repository.user=username
# svnant.repository.passwd=password
# svnant.project.url=svn://XXX.XXX.XX.XX/path/to/project
# -----------------------------------------------------------------------------
 
svnant.repository.user=username
svnant.repository.passwd=password
svnant.project.url=svn://path.to.your.repo.project/trunk
 
# -----------------------------------------------------------------------------
# Build Folder Locations
# Example:
# temp.dir=temp
# build.dir=release
# -----------------------------------------------------------------------------
 
temp.dir=/temp/scratch
build.dir=/temp/release
 
# -----------------------------------------------------------------------------
# Comment File Location, Where we output revision information requires tokens
# in file: @build-revision@
# -----------------------------------------------------------------------------
 
comment.file.path=/your-app/views/scripts/common/footer.phtml
 
# -----------------------------------------------------------------------------
# Deploy Location and Login
# Example:
# deploy.server=sugababes.com
# deploy.path=/path/to/directory
#
# -----------------------------------------------------------------------------
 
deploy.server=productionserver.com
deploy.path=/full/path

build.xml

Contained within the build XML file are all the tasks used by ANT. First the tasks we will actually run:

• build-release : checksout and builds release (good for testing without sending to production)
• deploy-release : deploys release and expands on target server
• build-deploy : a short cut that builds and releases to production in one step (most commonly used)

The above relies on the following ANT tasks to do the actual work:

• clean : clean up from any previous builds
• checkout : checkout project from subversion
• cleanRelease : removes folders that should not be deployed (documentation, the build folder)
• populate : copy and rename the correct htaccess file, remove old one
• revision : find token in file, replace with revision number and date/time stamp
• zip release : compress file
• deploy : use scp to transfer zip file
• extractConfigure : delete existing files on target server, extract zip file on target server.

* Apologies for the weird indentation below, the wordpress plugin for syntax coloring is mangling tabs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139

<?xml version="1.0"?>
<project name="DevPatch Client App" basedir="." default="usage">
 
<description>
    Build File For DevPatch Client Zend Deployment - checkout from subversion,
    cleans release, creates zip file and scp file to the correct environment.
</description> 	
 
<property file="build.properties.${env}" /> 
 
<!-- ===================================================== --> 
<!-- Subversion                                            -->
<!-- ===================================================== --> 	
    <path id="project.classpath">
        <pathelement location="${svnjavahl.jar}" /> 
        <pathelement location="${svnant.jar}" />
        <pathelement location="${svnClientAdapter.jar}" />
    </path>
 
    <typedef resource="org/tigris/subversion/svnant/svnantlib.xml"
        classpathref="project.classpath"  />  
 
    <target name="checkout">
        <svn username="${svnant.repository.user}" 
             password="${svnant.repository.passwd}">
 
            <checkout url="${svnant.project.url}" 
             revision="${revision}" 
             destPath="${temp.dir}" />
        </svn>
    </target>
 
<!-- ===================================================== --> 
<!-- Utility & Clean Up                                    --> 
<!-- ===================================================== --> 		
   <target name="clean">
      <delete dir="${temp.dir}"/>
   </target>	
 
   <target name="cleanRelease">
      <delete dir="${temp.dir}/build" />
      <delete dir="${temp.dir}/db" />	
      <delete dir="${temp.dir}/docs" />		 
   </target>
 
<!-- ===================================================== --> 
<!-- Replace Token In Footer With Revision Number          --> 
<!-- ===================================================== --> 	
   <target name="revision">
      <svn>
         <status path="${temp.dir}" revisionProperty="Revision" />
      </svn>
      <tstamp/>
      <replace file="${temp.dir}${comment.file.path}" 
               token="@build-revision@" 
               value="Revision: ${Revision}, Built On: ${DSTAMP} : ${TSTAMP}"/>
   </target>
 
<!-- ===================================================== --> 
<!-- Copy/rename correct htaccess file. Remove existing    -->
<!-- file                                                  --> 
<!-- ===================================================== --> 	
    <target name="populate">
        <delete file="${temp.dir}/public/clients-admin/.htaccess"/>    
        <copy file="${temp.dir}/public/clients-admin/htaccess.${env}" 
            tofile="${temp.dir}/public/clients-admin/.htaccess"/>	
        <delete file="${temp.dir}/public/clients-admin/htaccess.${env}"/>    
   </target>                  
 
<!-- ===================================================== --> 
<!-- zip release                                           --> 
<!-- ===================================================== --> 		
	<target name="zipRelease">
		<mkdir dir="${build.dir}"/>
		<zip destfile="${build.dir}/YOUR-FILE-NAME_${revision}.zip" 
		     basedir="${temp.dir}" />
		<antcall target="clean"/>
	</target>
 
<!-- ===================================================== --> 
<!-- deploy to target server                                  --> 
<!-- ===================================================== --> 	
	<target name="deploy">
		<scp file="${build.dir}/YOUR-FILE-NAME_${revision}.zip"
			todir="${user}@${deploy.server}:${deploy.path}" 
			password="${pass}"
			trust="true"
		/>
	</target>
 
<!-- ===================================================== --> 
<!-- Extract and configure on target server, delete        --> 
<!-- manually everything, create data folder        -->
<!-- set correct dir permissions                           --> 
<!-- ===================================================== --> 	
	<target name="extractConfigure">
        <sshexec host="${deploy.server}"
        			  username="${user}"
	              password="${pass}"
	              trust="yes"
	              command="cd ${deploy.path}; 
	                      rm -R app-clients-admin;
	                      rm -R library;
	                      rm -R public;	
	                      rm -R data;	   
	                      mkdir data;
	                      mkdir data/cache;
	                      mkdir data/session;	                                           
	                      chmod 775 data/cache;
	                      chmod 775 data/session;
                          unzip -o YOUR-FILE-NAME_${revision}.zip;
                          rm YOUR-FILE-NAME_${revision}.zip;   
                         "/>
	</target>	
 
<!-- ===================================================== --> 
<!-- Targets               				--> 
<!-- ===================================================== --> 			
	<target name="build-release" 
			description="Checksout and Build Release, Specify revision and environment (prod) 
			             Example: ant build-release -Drevision=HEAD -Denv=prod" 
			depends="clean,checkout,cleanRelease,populate,revision,zipRelease"/>
 
  	<target name="deploy-release" 
  			description="Deploys Release and Expands on Target Server 
  			             Example: ant deploy-release -Drevision=value -Denv=prod -Duser=value -Dpass=value"
  			depends="deploy,extractConfigure" />
 
  	<target name="build-deploy" 
  	      description="Checksout,Build, Deploys in One Step
  	                   Example: ant build-deploy -Drevision=value -Denv=prod -Duser=value -Dpass=value"
  			depends="clean,checkout,cleanRelease,populate,revision,zipRelease,deploy,extractConfigure" />  			
 
	<target name="usage"> 
		<echo message="  Execute 'ant -projecthelp' for build file help."/> 
		<echo message="  Execute 'ant -help' for Ant help."/> 
	</target>   	
 
</project>

cleanRelease and extractConfigure is where you will likely need to do the most customizing. For example during extractConfigure I remove my data directory where I store cache/session data then re-create. This is something specific to my application.

When running the ANT targets you supply the revision (or HEAD) the target environment (just prod in the example), and the username/password for your production environment:

Example: ant build-deploy -Drevision=HEAD -Denv=prod -Duser=foo -Dpass=foobar

The env variable is used to specify which properties file to use and which htaccess file to copy. If you supplied qa, ANT would look for build.properties.qa and htaccess.qa.

Running ant -projecthelp will show you the 3 main targets and examples of their usage.

Firebug – Firefox Plugin

Firebug is my workhorse for general debugging. It has the standard set of CSS inspectors and a robust net monitor. The net monitor is essential for debugging XHR requests. I could not develop Ajax applications without it.

Chrome – Developer Tools

Google’s chrome browser comes with an amazing set of developer tools and is quickly replacing firebug in my toolkit. It has all the standard CSS inspectors and JS debuggers but goes a bit further than firebug. I was blown away when I discovered CPU profiling. This is a great way to sniff out memory leaks, really important if you are adding/removing DOM elements like a madman.

Also important to point out are the JS timeline tools, showing you a breakdown of loading, scripting, rendering while you are interacting with the web page. Another great tool for optimizing speed.

Pixel Perfect – Firefox Plugin

The ultimate tool for making sure you have translated a design to HTML with pixel perfect accuracy. Pixel Perfect allows you to overlay an image onto a web page and manipulate it’s opacity. This makes it incredibly simple to compare a design mockup and your HTML.

http://developer.yahoo.com/yui/theater/

Here is the use case I am addressing: I want to store routes in a .ini file and have this file loaded via the Application Bootstrap. Zend Application allows me to store these in the application.ini file but I have a large number and want to store them separately.

First create your routes.ini file:

configs/routes.ini

1
2
3
4

[production]
routes.linkA.route = "linkA"
routes.linkA.defaults.controller = "linkB"
routes.linkA.defaults.action = "linkBAction"

Where linkA is the incoming route and linkB is the outgoing route

New let’s add the function to load this file in the Bootstrap. Add the following to your boostrap.php:

1
2
3
4
5
6
7

protected function _initRewrite() {
    $front = Zend_Controller_Front::getInstance();
    $router = $front->getRouter();
 
    $config = new Zend_Config_Ini(APPLICATION_PATH . '/configs/routes.ini', 'production');      
    $router->addConfig($config,'routes');
}

That’s it, everything should be working

The above use case is addressed in the Zend Framework Documentation but I could not get their example to work:

http://framework.zend.com/manual/en/zend.controller.router.html

Using Zend_Config with the RewriteRouter
Sometimes it is more convenient to update a configuration file with 
new routes than to change the code. This is possible via
the addConfig() method. 
 
 . . .
 
$config = new Zend_Config_Ini('/path/to/config.ini', 'production');
$router = new Zend_Controller_Router_Rewrite();
$router->addConfig($config, 'routes');

No matter how hard I tried I could not get the above to work. It is very simple code but there are no instructions on where this can/should be run. Maybe this can’t be run from the bootstrap? I even wrote a plugin and but no matter what I tried I could not get this to work using Zend_Controller_Router_Rewrite().

It is also possible that I completely mis-understood the documentation and got all mixed up, I struggle with Zend Documentation sometimes.

If you figure out how to do this using Zend_Controller_Router_Rewrite() please leave a comment it was driving me nuts!

Node.js is evented i/o for Google’s V8 Server Side JavaScript engine. For me . . . node.js means I can write apps that can handle tons of requests without having to learn/think about threads & locks (all I know about threads is that they are scary and involve big books from O’reilly).

As a front-end developer the node.js approach is fantastic because I already think in terms of events and I love writing code in JavaScript.

Installing node.js on OS X is super-easy and the documentation on the node.js site is great, but I figured I would write a step-by-step for OS X since I had just installed it for the first time. The node.js install includes Google’s V8 JS engine so no need to worry about installing that.

Download and Install Node.JS

Get node.js from either github or download from the node.js site. If you need GIT for OS X you can grab the code from google http://code.google.com/p/git-osx-installer/ and follow GitHub’s install instructions.

http://github.com/ry/node

http://nodejs.org/#download

Build & Install

Build node.js by following the instructions in the readme or just run:

1
2
3

 ./configure
 make 
 make install

At this stage you may get an error about a missing compiler (I did). This can be caused by outdated developer tools or completely missing developer tools. In my case I did not run the Xcode install from my Snow Leopard Disc when I upgraded. So if you get this error grab your Snow Leopard DVD, put the kettle on, and run the Xcode installer.

You may also get a permissions error running make install, in this case just sudo make install.

Test Server With Hello World

Copy the test server code from below (taken directly from http://nodejs.org):

1
2
3
4
5
6
7
8
9
10
11

var sys = require('sys'),
    http = require('http');
 
    http.createServer(function (req, res) {
        setTimeout(function () {
            res.writeHead(200, {'Content-Type': 'text/plain'});
            res.end('Hello World\n');
        }, 2000);
    }).listen(8000);
 
sys.puts('Server running at http://127.0.0.1:8000/');

Run it with:

node example.js

And go the the following url in a browser:

http://127.0.0.1:8000/

You should see the text “hello world”. If you do congrats, node.js is installed!

In my approach loading up different CSS/JS files per controller is the exception not the rule. We load additional CSS/JS when we need to do something very special, for example a page with a flash file uploader.

I also think loading dependent files outside of the controller can make it difficult for other developers to work on your code. You can’t just look at the controller to see what other CSS/JS dependencies are being used, you need to check the file system.

My approach is a View Plugin that manages a standard set of CSS/JS for every layout. Additional CSS/JS if needed are added in the controllers.

Onto the code!

View Plugin Example

Here is my example view plugin from a recent project:

/app/plugins/View.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<?php
class Plugin_View extends Zend_Controller_Plugin_Abstract {
    public function routeStartup() {
 
        $view = new Zend_View();
 
        $view->doctype('XHTML1_STRICT');
        $view->headTitle()->setSeparator(' - ')->append('FooBar.com');
        $view->headMeta()->appendHttpEquiv('Content-Type','text/html; charset=utf-8');
        $view->headLink()->appendStylesheet('/css/style.css');
 
        $view->addHelperPath('ZendX/JQuery/View/Helper/', 'ZendX_JQuery_View_Helper');
        $view->jQuery()->enable(); 
        $view->jQuery()->uiEnable();  
 
        $view->jQuery()->setLocalPath('/js/jquery/jquery-1.3.2.min.js');
        $view->jQuery()->setUiLocalPath('/js/jquery/jquery-ui-1.7.2.custom.min.js');  
        $view->jQuery()->addStylesheet('/css/smoothness/jquery-ui-1.7.2.custom.css');
        $view->jQuery()->addJavascriptFile('/js/interface-utils.js');
 
        $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
        $viewRenderer->setView($view);  
        Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
    }
}

The code in an example layout file:

/app/views/layout/login.php

1
2
3
4
5
6
7
8
9
10
11

<?= $this->doctype() ?>
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>  
  <?= $this->headMeta() ?>
  <?= $this->headLink() ?>
  <?= $this->jQuery() ?>        
  <?= $this->headScript() ?> 
  <?= $this->headTitle()?> 
 
</head> 
<body>

As you can see from the above code, the Plugin handles everything needed for the HEAD area of the page, and it is all in one place.

Adding Additional CSS/JS From A Controller

If you need to add additional CSS/JS files, you can now do this in the controller – when needed. In the following example I need to add the dependencies for “Uploadify” a flash based multifile uploader.

/app/controllers/UploadController.php

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php
 
class UploadController extends Zend_Controller_Action {
 
    public function init() {    
 
    }
 
    public function indexAction() {
        $this->view->headLink()->appendStylesheet('/uploadify/uploadify.css');
        $this->view->headScript()->appendFile('/uploadify/swfobject.js');
        $this->view->headScript()->appendFile('/uploadify/jquery.uploadify.v2.1.0.min.js');          
    }

The above inserts the dependencies into the layout for this controller action only. Sweet!!

From my perspective this approach works better and I think from a code organization structure it is cleaner. Any special CSS/JS can be added on a per-controller or per-controller-action basis and it will be very clear to other developers what is being loaded and where.

Font Squirrel has a great online conversion tool that handles generating the fonts/CSS and everything for you. All you need is the TrueType or OpenType version of the font.

http://www.fontsquirrel.com/fontface/generator

It will even base64 encode the font, allowing you embed the entire font into your CSS (rather than having a file) to avoid the “text flashing/switching” that can occur.

Be aware that you will need to encode all variants of the font you want to use, including bold/italic so keep an eye on your file size.

I will be using the blog section to share technical tips & tricks focusing on:

• XHTML & HTML 5
• jQuery
• Server Side JavaScript
• Zend Framework
• Technical Project Management

Special thanks to Lesley Marker @ Marker Design for developing the DevPatch logo/branding.