New Media Campaigns

Following content management's core concepts with your CMS

Tue, 10 Nov 2009 10:00:00 EST

Content Management is nothing new, but it does have its fair share of growing pains as it relates to the web. With the number of options readily available, it is easy for designers, developers and clients to lose sight of content management's core principals:

Sorting 'Stuff' — content defined by an end-user — into a content repository.
Support the workflow of the end-user.

The web community has the first principal down thanks to relational databases, but we really struggle with the second. Since the end-user can vary from an individual with varying skill sets to a large corporation with endless resources, demands on a Content Management Systems and its specific workflow have create countless options in the marketplace.

With each options comes a list of pros and cons, fanboys and detractors which ends up creating some misconceptions. Here are some misconceptions I've read repeatedly in the last few weeks that neglect to take these core principals into account:

One type of system is better than other.

Is it better to go open source, third-party or proprietary system? Truthfully, there is no right answer because each option can meet your goal of publishing content to the web but could create a potential workflow nightmare.

I use to advocate for using third-party software. I preferred working with a system that offered continuing support thanks to its customer base. If I was unable to continue to help client with maintenance there was always someone within the community. Now a client would never feel like they've wasted their investment on piece of technology.

That philosophy helped me in large part but I'm not sure it was in my clients best interest. When I started using other technology that better suited their workflow needs, I found myself getting more projects in the long run. Just because a company can afford an expensive system doesn't mean Wordpress isn't the best solution for their needs.

With the volume of clients and sites we work on, our proprietary system has proven the best option over time and I realized that within my first few days here.

CMSs should be more open to customization.

I think there is a false perceptions in the title 'Content Management System.' People seem to infer that they should have more control over the system itself and this can lead to people neglecting the content itself. Not all systems are created equal, so you can't be under the assumption any system will meet your needs.

If you feel like your system can't be customized, you have either chosen a system that doesn't fit into your workflow or you didn't define your content before development began on your system (I'll discuss defining your content in a future post). By ignoring your content from the start, you won't have a clear understanding of the work needed to publish your content and you will feel limited by any system.

Buying into a system means that you are committing to a set of standards, like a fixed design, so that you can produce and manage content quickly be streamlining your workflow. If you can't conform to any set of standards, moving to a CMS isn't in your best option.

I don't need to learn HTML now that I have a CMS.

The point of moving to a CMS is to avoid coding and/or reduce the reliance of a developer to speed up your publishing process, creating a better workflow. So why would I have to learn HTML when I have a WYSWYG editor to do the work for me?

You don't.

While there is no need to learn the syntax of a web language like HTML still you need to have an general understanding of how it works. You need to realize that pasting source code info your CMS from an e-mail newsletter is going to break your page in all likelihood. You need to realize when something is outside of the workflow of publishing content.

CMSs are bad for SEO

This goes back to the same ideas with customization: If you don't make SEO part of your workflow and create/use a system with it in mind early, it's going to make it harder to have good SEO. If that's the case, is it the systems' fault or yours?

Conclusion

The success of any CMS is tied to its ability to conform to your workflow. Most complaints with specific systems can be drawn to the fact they weren't developed with your particular workflow in mind. After all, the end goal of using a system is to publish and management content easily and quickly. Most systems can accomplish that, which is align with the first principal.

Having only worked with our in-house system for a few days, I can tell the team put careful thought into the workflow and it seems to be paying dividends.

Three Ways to Target Mobile Devices

Mon, 09 Nov 2009 11:05:00 EST

We recently launched a beta version of a New Media Campaigns mobile Webkit site. If you're reading this post from an iPhone, iTouch, Palm Pre or Android based phone you're seeing it right now. Josh Lockhart did the design and frontend code for the site, a topic he will be covering in a post later this week.

This post discusses how to target mobile devices and show them either different content, different stylesheets or even redirect to a mobile URL. Ideally, the check would be done for ALL mobile webkit platforms, not just the iPhone. It would be a shame to leave those Android/Palm out after developing a pretty mobile site. So without further ado, here are the methods:

1. Checking User Agent Serverside

When a browser visits a site, it sends a string describing who it is called the user-agent string. It varies depending on the browser and platform. The user-agent string for key mobile webkit browsers are:

iPhone - Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3
iTouch - Mozilla/5.0 (iPod; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like Gecko) Version/3.0 Mobile/3A100a Safari/419.3 
Android - Mozilla/5.0 (Linux; U; Android 0.5; en-us) AppleWebKit/522+ (KHTML, like Gecko) Safari/419.3
Palm Pre - Mozilla/5.0 (webOS/1.0; U; en-US) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/1.0 Safari/525.27.1 Pre/1.0

Unfortunately there is not a good way to check for mobile webkit in general. So each of these needs to be checked for in a case by case manner. Here is some rough php to do that:

if( strstr($_SERVER['HTTP_USER_AGENT'],'Android') ||
	strstr($_SERVER['HTTP_USER_AGENT'],'webOS') ||
	strstr($_SERVER['HTTP_USER_AGENT'],'iPhone') ||
	strstr($_SERVER['HTTP_USER_AGENT'],'iPod')
	){
	// Send Mobile Site
}

We did this type detection since we wanted to send completely new templates for pages at the same URL. This worked nicely with our CMS since both the normal frontend and the mobile fronend were updated from the same database. We could also use this technique to redirect to a mobile URL if that is how we wanted to present our mobile site.

2. Checking User Agent Clientside

This method simply uses javascript to check the User Agent after the page has loaded. The obvious downside is that it first requires mobile visitors to load your standard site which might be fairly heavy. It is fine to use in a pinch where you are not able to modify server-side code.

Here is some javascript to detect the mobile webkit browsers:

if( navigator.userAgent.match(/Android/i) ||
	navigator.userAgent.match(/webOS/i) ||
	navigator.userAgent.match(/iPhone/i) ||
	navigator.userAgent.match(/iPod/i) ||
	){
 // Send Mobile Site
}

You can use this method to either redirect to a different site, send a different stylesheet or whatever else you may need to do for a mobile site.

3. Use CSS Media Type

If your HTML doesn't need to change between your mobile site and standard site, it may make more sense to send a different stylesheet just to mobile browsers. There are a couple of ways to do this, but using the media type capabilities of CSS may be the way to go.

To load an entirely different stylesheet, use the media attribute when loading the stylesheet:

<link href="mobile.css" rel="stylesheet" type="text/css" media="only screen and (max-device-width: 480px)" />

Alternatively you can just add some declarations into your existing stylesheet:

@media screen and (max-device-width: 480px) {
    /* mobile declarations */
}

This method is a little dangerous since it depends on the screen resolution to send the stylesheet. A mobile site is generally not different from a typical site because of resolution alone; it is also different because of the physical screen size of the device. For instance, the new Verizon Droid has roughly the same screen dimensions of the iPhone but a resolution of 854px by 440px! Serving a mobile site to this device makes sense even though it has such high resolution.

If you've done a mobile site and have a perferred method be sure to share the site and the method in the comments.

Easy menus with nmcDropDown

Mon, 02 Nov 2009 10:55:00 EST

Since I released my nmcDropDown plugin for jQuery two weeks ago, several people have been asking for a simple example of how to use it. Althought the plugin takes care of all the behavior automatically, you still need to style and format the menu using CSS. In this post I will demonstrate two simple menu styles that use nmcDropDown.

The bare minimum

The examples below have styling and effects to make them look nice, but first I will show you the minimum you need to get your menus running. First off, you need a set of nested lists and link to create the structure of your menus:

<ul id="nav">
  <li><a href="#">Item One</a>
    <ul>
      <li><a href="#">Sub-menu Item 1</a></li>
      <li><a href="#">Sub-menu Item 2</a></li>
      <li><a href="#">Sub-menu Item 3</a></li>
    </ul>
  </li>
  <li><a href="#">Item Two</a>
    <ul>
      <li><a href="#">Sub-menu Item 1</a></li>
      <li><a href="#">Sub-menu Item 2</a></li>
      <li><a href="#">Sub-menu Item 3</a></li>
    </ul>
  </li>
  <li><a href="#">Item Three</a>
    <ul>
      <li><a href="#">Sub-menu Item 1</a></li>
      <li><a href="#">Sub-menu Item 2</a></li>
      <li><a href="#">Sub-menu Item 3</a></li>
    </ul>
  </li>
</ul>

Now you need a bit of CSS to put everything in its correct place. This menu isn't going to look nice, but it will give you a starting point from which you can match your site's overall aesthetic.

#nav { float: right; height: 30px; }
#nav li { float: left; position: relative; }
#nav li a { display: block; padding: 5px 10px; line-height: 20px; }
#nav li ul { display: none; position: absolute; top: 30px; left: 0; width: 120px; background: #fff; }
#nav li:hover ul { display: block; }
#nav li ul li { float: none; }
#nav li ul li a { display: inline-block; }
#nav li ul li a { display: block; }

The most important thing here is to set #nav li to position: relative; and #nav li ul to position: absolute; to the submenus are aligned with their parent item. In the interest of accessibility, we are also hiding the submenus in the CSS (#nav li ul { display: none; }) and showing them with their parent li is hovered over (#nav li:hover ul { display: block; }. That way, if JavaScript is disabled, the menus will still work in every browser but Internet Explorer 6. JavaScript is always required for drop-downs to work in IE6, unfortunately. Speaking of which, did you notice the oddity at the end where we declare the links as display: inline-block and then re-declare them at display: block? That is the only concession we need to make to Internet Explorer bugs—it removes the extra space IE6 inserts between list items, as discovered by Roger Johansson.

This CSS will create a horizontal menu with drop-downs, but by changing a few lines, you could just as easily make it a vertical menu with fly-outs.

Finally, the JavaScript to hook up the nmcDropDown script. Make sure you also paste the nmcDropDown script itself (and the HoverIntent plugin, if you wish to use it) into the JavaScript file.

$('#nav').nmcDropDown();

Makin' it Pretty

Now that we have a functioning menu, we can start styling it. I have created an sample page with two different examples using nmcDropDown.

The first—in the top-right of the page—is based on the simplified example above, just with additional CSS to style the menu bar and drop-downs. I also added an additional parameter to the call in JavaScript to make the menus slide down instead of fading in: $('#nav').nmcDropDown({show: {height: 'show', opacity: 'show'}});.

The second example is a little more interesting, as it's actually not a menu at all. In the right-hand sidebar, I am using nmcDropDown to create an informational panel with four heading that, which clicked on, each reveal a bit of text. To do this, I replaced the second level of <ul>s in my HTML with paragraphs. I then used the following CSS to line arrange everything vertically:

#sidebarNav { padding: 10px 0; background: #ccc; border: 1px solid #bbb; -webkit-border-radius: 4px; -moz-border-radius: 4px; border-radius: 4px; }
#sidebarNav li { border-top: 0 solid #ccc; }
#sidebarNav li:hover, #sidebarNav li.open { background: #bbb; }
#sidebarNav li a { display: block; padding: 5px 10px; line-height: 20px; color: #444; font-weight: bold; text-decoration: none; }
#sidebarNav li p { display: none; padding: 5px 10px 10px; color: #444; border-top: 1px dashed #aaa; }
#sidebarNav li:hover p { display: block; }

Finally, in the JavaScript I told nmcDropDown to activate on click rather than hover and to look for my paragraph instead of the unordered-list it usually expects:

$('#sidebarNav').nmcDropDown({
  trigger: 'click',
  submenu_selector: 'p',
  show: {height: 'show'},
  hide: {height: 'hide'}
});

Please look at the sample page to try these out, and view source to examine the code in more detail. If you find another creative way to use nmcDropDown, please link to it in the comments.

How to create a blog with the Recess PHP Framework, Part 3

Wed, 28 Oct 2009 11:55:00 EDT

This is the third article in my Recess Framework blog tutorial that will demonstrate how to create model relationships with the Recess PHP Framework. Previously in this tutorial, we learned how to list and display individual blog posts, and more recently, how to create, update and delete blog posts using Recess’ ORM (object relational mapper). This tutorial assumes you have completed the previous tutorials. If you have not completed the previous tutorials, you should download the most current version of our blog application before reading further.

As I explained in my previous tutorial, [BLOG_ROOT] references the filesystem directory where you have installed the Recess PHP Framework; on my machine, [BLOG_ROOT] is ~/Sites/recess/. [BLOG_URL] references the URL with which you can access the blog application in a web browser; on my machine [BLOG_URL] is http://localhost/~joshlockhart/recess/.

Authors

We will create a one-to-many model relationship between authors and blog posts. One author writes many blog posts, and each blog post belongs to only one author. If we were using a user authentication system, we could determine the author based on the logged-in user writing the post. We will explore user authentication with Recess later in this tutorial series. For now, we will display a combo-box on the Write Post and Edit Post forms that will display a list of available authors. Let’s get started. We first need to create the controller, models, and views for authors. Since this process was discussed in detail in the previous two two tutorials, I will move quickly through this process assuming you are familiar with these steps.

Creating the Author database table

Create the authors table in your SQLite database with the following SQL commands:

CREATE TABLE `authors` (
    `id` INTEGER PRIMARY KEY,
    `name_first` TEXT,
    `name_last` TEXT
);
INSERT INTO `authors` VALUES (1,'John','Doe');
INSERT INTO `authors` VALUES (2,'Jane','Doe');

Next, update the posts database table and add an “author_id” foreign key:

ALTER TABLE `posts` ADD `author_id` INTEGER;

Last, let’s make sure all existing posts are assigned to the first author.

UPDATE `posts` SET `author_id` = 1;

Creating the Author model

Next, create the Author model at [BLOG_ROOT]apps/blog/models/Author.class.php and insert the following code:

<?php
/** 
 * !Table authors
 */
class Author extends Model {}
?>

Creating the Author controller

The Author controller is responsible for listing, creating, updating, and deleting blog authors. Create [BLOG_ROOT]apps/blog/controllers/AuthorsController.class.php and insert the following code:

<?php
Library::import('recess.framework.controllers.Controller');
Library::import('blog.models.Author');

/**
 * !RespondsWith Layouts
 * !Prefix Routes: /, Views: authors/
 */
class AuthorsController extends Controller {

    /** !Route GET, authors */
    public function listAuthors(){
        $author = new Author();
        $this->authors = $author->all();
    }

    /** !Route GET, authors/$id */
    public function show($id){
        $author = new Author($id);
        $this->author = $author->find()->first();
    }

    /** !Route GET, authors/new */
    public function newAuthor(){
        $this->author = new Author();
    }

    /** !Route POST, authors */
    public function create(){
        $author = new Author($this->request->post['author']);

        if( $author->save() ){
            return $this->redirect($this->urlTo('listAuthors'));
        } else {
            return $this->ok('newAuthor');
        }
    }

    /** !Route GET, authors/$id/edit */
    public function edit($id){
        $author = new Author($id);

        if( $author->exists() ){
            $this->author = $author->find()->first();
        } else {
            return $this->redirect($this->urlTo('listAuthors'));
        }
    }

    /** !Route PUT, authors/$id */
    public function update($id){
        $author = new Author($id);

        if( $author->exists() ){
            $this->author = $author->find()->first()->copy($this->request->put['author']);
            if( $this->author->save() ){
                //set a success message if necessary
            }
            return $this->redirect($this->urlTo('edit',$id));
        } else {
            return $this->redirect($this->urlTo('listAuthors'));
        }
    }

    /**
     * !Route DELETE, authors/$id
     * !Route GET, authors/$id/delete
     */
    public function delete($id){
        $author = new Author($id);

        if( $author->exists() ) $author->delete();
        return $this->redirect($this->urlTo('listAuthors'));
    }

}

?>

Creating the Author view templates

Now, let’s quickly create the templates for the Author CRUD actions. Create [BLOG_ROOT]apps/blog/views/authors/listAuthors.html.php and insert the following markup:

<html>
    <body>
        <h1>Authors</h1>
        <ul>
            <?php foreach( $authors as $author ): ?>
            <li>
                <h2><a href="<?php echo Url::action('AuthorsController::show',$author->id); ?>"><?php echo $author->name_first . ' ' . $author->name_last; ?></a></h2>
                <p>
                    <a href="<?php echo Url::action('AuthorsController::edit',$author->id); ?>">Edit</a>
                    <a href="<?php echo Url::action('AuthorsController::delete',$author->id); ?>" onclick="return confirm('Are you sure?');">Delete</a>
                </p>
            </li>
            <?php endforeach; ?>
        </ul>
    </body>
</html>

You can view the author list at [BLOG_URL]index.php/blog/authors/. Next, create [BLOG_ROOT]apps/blog/views/authors/show.html.php and insert the following markup:

<html>
    <body>
        <h1><?php echo $author->name_first . ' ' . $author->name_last; ?></h1>
    </body>
</html>

You can view each author’s page at [BLOG_URL]index.php/blog/authors/1 (where ‘1’ is the ID of a given author). Next, create [BLOG_ROOT]apps/blog/views/authors/newAuthor.html.php and insert the following markup:

<html>
    <body>
        <h1>Add Author</h1>
        <form action="<?php echo Url::action('AuthorsController::create'); ?>" method="POST">
            <fieldset>
                <label for="firstName">First Name</label><br/>
                <input type="text" id="firstName" name="author[name_first]" value=""/><br/>
                <label for="lastName">Last Name</label><br/>
                <input type="text" id="lastName" name="author[name_last]" value=""/><br/>
                <input type="submit" value="Add Author"/>
            </fieldset>
        </form>
    </body>
</html>

You can view the Add Author form at [BLOG_URL]index.php/blog/authors/new. Next, create [BLOG_ROOT]apps/blog/views/authors/edit.html.php and insert the following markup:

<html>
    <body>
        <h1>Edit Author</h1>
        <form action="<?php echo Url::action('AuthorsController::update',$author->id); ?>" method="POST">
            <fieldset>
                <label for="firstName">First Name</label><br/>
                <input type="text" id="firstName" name="author[name_first]" value="<?php echo $author->name_first; ?>"/><br/>
                <label for="lastName">Last Name</label><br/>
                <input type="text" id="lastName" name="author[name_last]" value="<?php echo $author->name_last; ?>"/><br/>
                <input type="hidden" name="_METHOD" value="PUT"/>
                <input type="submit" value="Update Author"/>
            </fieldset>
        </form>
    </body>
</html>

You can view the Edit Author form at [BLOG_URL]index.php/blog/authors/1/edit (where ‘1’ is the ID of a given author). Next, create blank template files at [BLOG_ROOT]apps/blog/views/authors/create.html.php and [BLOG_ROOT]apps/blog/views/authors/update.html.php and [BLOG_ROOT]apps/blog/views/authors/delete.html.php. Although these templates are not necessary for our application, Recess requires a template for each public controller action to avoid throwing errors. The creators of Recess will remedy this behavior in a future framework update.

We are now able to list, view, add, update, and delete blog authors. Now let’s relate authors to posts.

Associating Authors to Posts

Updating the models

We need to tell Recess that each post belongs to one author. Open [BLOG_ROOT]apps/blog/models/Author.class.php and update it’s contents to look like this:

<?php
/** 
 * !Table authors
 * !HasMany posts, Key: author_id
 */
class Author extends Model {}
?>

We use a Recess declarative annotation to describe our Author model. In this example, we say that an Author !HasMany posts. We also specify the foreign key column used by the related model if the foreign key column name is different from convention; by default, Recess expects a foreign key column name of “authorId”. I like to suffix my foreign keys with "_id", so I needed to clarify this in the !HasMany annotation. Let’s now update [BLOG_ROOT]apps/blog/models/Post.class.php:

<?php
/**
 * !Table posts
 * !BelongsTo author, Key: author_id
 */
class Post extends Model {}
?>

We use a Recess declarative annotation to describe our Post model; a Post !BelongsTo one author. We also specify the foreign key column used by this relationship. The annotation on the Post model assumes the posts database table has an “author_id” foreign key column that references an existing Author database record. We added this foreign key earlier in this tutorial.

Updating the views

Let’s now update our Write Post and Edit Post templates so that we may select an author when we write or edit a post. Before we edit the templates, we need to make sure we pass an array of available authors from the PostsController::write() and PostsController::edit() actions. Open [BLOG_ROOT]apps/blog/controllers/PostsController.class.php. Edit the PostsController::write() action to look like this:

/** !Route GET, posts/write */
public function write(){
    $this->post = new Post();
    $author = new Author();
    $this->authors = $author->all();
}

And update the PostsController::edit() action to look like this:

/** !Route GET, posts/$id/edit */
public function edit($id){
    $post = new Post($id);

    if( $post->exists() ){
        $this->post = $post->find()->first();
        $author = new Author();
        $this->authors = $author->all();
    } else {
        return $this->redirect($this->urlTo('listPosts'));
    }
}

Since we reference the Author model in the Posts controller, we need to import the Author model into our controller. Add this line to the existing import statements at the top of PostsController.class.php:

Library::import('blog.models.Author');

Now we can update our templates. Open [BLOG_ROOT]apps/blog/views/home/write.html.php and update it to look like this. I have highlighted the changes.

<html>
    <body>
        <h1>Write Post</h1>
        <form action="<?php echo Url::action('PostsController::create'); ?>" method="POST">
            <fieldset>
                <label for="title">Title</label><br/>
                <input type="text" id="title" name="post[title]" value=""/><br/>    
                <label for="content">Content</label><br/>
                <textarea id="content" name="post[content]" rows="20" cols="50"></textarea><br/>
                <label for="author">Select an author:</label><br/>
                <select id="author" name="post[author_id]">
                    <?php foreach( $authors as $author ): ?>
                    <option value="<?php echo $author->id; ?>"><?php echo $author->name_first .' '.$author->name_last; ?></option>
                    <?php endforeach; ?>
                </select><br/><br/>
                <input type="submit" value="Create Post"/>
            </fieldset>
        </form>
    </body>
</html>

Next, open [BLOG_ROOT]apps/blog/views/home/edit.html.php and update the markup so it looks like this. I have highlighted the changes.

<html>
    <body>
        <h1>Update Post</h1>
        <form action="<?php echo Url::action('PostsController::update',$post->id); ?>" method="POST">
            <fieldset>
                <label for="title">Title</label><br/>
                <input type="text" id="title" name="post[title]" value="<?php echo $post->title; ?>"/><br/>    
                <label for="content">Content</label><br/>
                <textarea id="content" name="post[content]" rows="20" cols="50"><?php echo $post->content; ?></textarea><br/>
                <label for="author">Select an author:</label><br/>
                <select id="author" name="post[author_id]">
                    <?php foreach( $authors as $author ): ?>
                    <option value="<?php echo $author->id; ?>" <?php if($author->id == $post->author_id): ?>selected="selected"<?php endif; ?>><?php echo $author->name_first .' '.$author->name_last; ?></option>
                    <?php endforeach; ?>
                </select><br/><br/>
                <input type="hidden" name="_METHOD" value="PUT"/>
                <input type="submit" value="Update Post"/>
            </fieldset>
        </form>
    </body>
</html>

When we edit an existing post, the correct author will be pre-selected.

Relationships in Action

We have successfully related Authors to Posts. Let’s see an example of this relationship in action by displaying all posts written by an author on the Show Author page. Open [BLOG_ROOT]apps/blog/views/authors/show.html.php and update its markup like this:

<html>
    <body>
        <h1><?php echo $author->name_first . ' ' . $author->name_last; ?></h1>
        <ul>
            <?php foreach( $author->posts() as $post ): ?>
            <li><a href="<?php echo Url::action('PostsController::show',$post->id); ?>"><?php echo $post->title; ?></a></li>
            <?php endforeach; ?>
        </ul>
    </body>
</html>

Last, let’s place a link to the author’s page beneath each blog post’s title. Open [BLOG_ROOT]apps/blog/views/home/listPosts.html.php and update the markup as shown below. The changes are highlighted.

<html>
    <body>
        <h1>Posts</h1>
        <ul>
            <?php foreach( $posts as $post ): ?>
            <li>
                <h2><a href="<?php echo Url::action('PostsController::show',$post->id); ?>"><?php echo $post->title; ?></a></h2>
                <p>By <a href="<?php echo Url::action('AuthorsController::show',$post->author()->id); ?>"><?php echo $post->author()->name_first . ' ' . $post->author()->name_last; ?></a> | Posted on <?php echo strftime("%B %e, %Y", $post->created); ?></p>
                <p><?php echo $post->content; ?></p>
                <p>
                    <a href="<?php echo Url::action('PostsController::edit',$post->id); ?>">Edit</a>
                    <a href="<?php echo Url::action('PostsController::delete',$post->id); ?>" onclick="return confirm('Are you sure?');">Delete</a>
                </p>
            </li>
            <?php endforeach; ?>
        </ul>
    </body>
</html>

Also open [BLOG_ROOT]apps/blog/views/home/show.html.php and update the markup as shown below. The changes are highlighted:

<html>
    <body>
        <h1><?php echo $post->title; ?></h1>
        <p>By <a href="<?php echo Url::action('AuthorsController::show',$post->author()->id); ?>"><?php echo $post->author()->name_first . ' ' . $post->author()->name_last; ?></a> | Posted on <?php echo strftime("%B %e, %Y", $post->created); ?></p>
        <p><?php echo $post->content; ?></p>
    </body>
</html>

Summary

This tutorial demonstrated how to relate the Author and Post models using declarative annotations. We also learned how to declare a custom foreign key on model relationships if the foreign key column name does not adhere to the Recess Framework naming convention. And finally, we learned how to take advantage of model relationships with the Recess Framework ORM in our templates. The next tutorial in this series will explore RESTful routing in the Recess Framework. Stay tuned!

Download the final project

This file contains the Recess Framework and all controllers, models, and views for this tutorial.

Download (ZIP, 356 KB)

AutoSprites - A jQuery Menu Plugin

Wed, 28 Oct 2009 11:15:00 EDT

Download the Files (Zip) | View a Demo

We have written and released a jquery dropdown menu plugin as well as a CSS Sprites2 Plugin -- this post is along the same lines. Its purpose is to allow you to build an image-based menu with animated hover states as easily as possible and by using the most concise descriptions possible. To see the results on both a horizontal and vertical menu, check out the demo.

Setting up the jQuery Menu Plugin

The first component when doing something with sprites is a combined image that contains all menu states. For the menu above, this is the image below was used. (This was designed by Liaison Design Group, one of our Partners)

The image contains both the normal state and the hover state. The value to doing things this way is that it allows your site to load faster. Rather than downloading an image for each nav item and its hoverstate, only a single image needs to be downloaded. This minimizes the overhead of many http requests.

The next thing to do, is set up the HTML for the nav bar:

<ul id="hnav"> 
	<li id="hnavhome"><a href="#">Home</a></li> 
	<li id="hnavlocal"><a href="#">Local Industry</a></li> 
	<li id="hnavhigher"><a href="#">Higher Education</a></li> 
	<li id="hnavcomm"><a href="#">Our Community</a></li> 
	<li id="hnavnews"><a href="#">News</a></li> 
</ul>

Then we need to set up the CSS. There are a couple of things to note here. We are applying the background image to the containing element so that we don't need to respecify background positioning. This also makes the menu usable if javascript is disabled. Each element needs to have its size defined specifically as well.

#hnav { position: absolute; top: 0; left: 0; width: 615px; height: 72px; background: url('horiz_sprites.gif') no-repeat; }
#hnav li { position: absolute; left: 0; height: 72px; }
	#hnav #hnavhome { width: 82px; left: 0px; }
	#hnav #hnavlocal { width: 146px; left: 82px; }
	#hnav #hnavhigher{ width: 162px; left: 228px; }
	#hnav #hnavcomm { width: 143px; left: 390px; }
	#hnav #hnavnews { width: 82px; left: 533px; }
#hnav li a { display: block; position: absolute; top: 0; left: 0; width: 100%; height: 72px; text-indent: -9999em; }

Notice how much less complicated the CSS is than what is typical with sprites. There is no need to define background positioning for each element and its hover state. The last piece you'll need to do is enable the autosprites plugin:

$(document).ready(function(){
	$('#hnav').autosprites();
});

There are no required options. The plugin defaults to a horizontal menu and fading for the animation. It infers everything else from the CSS. If you would like to customize things, here are the options that are available:

settings = $.extend({
	offset: '100%', //Can be specified in px as well. This tells the plugin the offset between the two sprites images
	orientation: 'horizontal', //'vertical' is the other option
	over: { opacity: 'show' },
	overSpeed: 500,
	out: { opacity: 'hide' },
	outSpeed: 500
}, settings);

So that's it! You can specify the minimum amount of information about your menu and the sprites will be built automatically. Be sure to check out the demo and download the zip for your own projects. As always leave a comment if you have any complements, insults, suggestions or questions.

A Special Note on Compiling Javascript

The purpose of using sprites is to minimize HTTP requests. It would be foolish to use this plugin by including jQuery, the minimized plugin, and a setup script. Instead, it is best practice on a production site to bring all of your scripts together into one file, just as sprites bring your images into one file.

Introductory Regular Expression Tutorial

Mon, 26 Oct 2009 17:00:00 EDT

Regular expressions are a handy tool for developers to use. They're a concise, domain-specific language for pattern matching text. Regular expressions have many applications: input validation, data extraction, and advanced search and replace are a few good examples. In this introductory regular expression tutorial we'll take a high-level tour of primary concepts. We'll avoid details for now and revisit them in follow-up tutorials.

Use our free regex tester to follow along with this tutorial. It is web-based and written in JavaScript so no download is necessary. We'll be using JavaScript style syntax, which is closely related to its Perl regex inspiration. Most modern language regex implementations use a syntax like Perl/JavaScript's but the details for executing match and replace are language specific.

Simple Text Finding

If you've ever used 'Find' in a program like your web browser or text editor you've used a tool akin to the most basic regular expressions. For example, the regular expression /hifi/g will match the string 'hifi'. It will not match 'HiFi' or 'high-fidelity'.

In order to match these three variations we can use regex choices, just like an OR.

This or That, Regex Choices

Choices are the 'OR' of regular expressions. The vertical bar character | denotes the "OR" between options. For example, /hifi|HiFi|high-fidelity/g, translates to 'hifi', or 'HiFi', or 'high-fidelity'.

What if we wanted to choose between two options in the middle of a regex match string? For example, what if we wanted to match the words ending in an 'ood' or 'ould' sound in the classic tongue-twister 'How much wood would a woodchuck chuck'? We could repeat a lot of information or'ing each of the words like /wood|would|could/g or we could use matching groups and use a choice in the middle of the string.

Regex Matching Groups

Create matching groups by pairing parenthesis around a part of the regular expression. They allow you to 'pick out' important parts of a large match with sub-expressions. That sounds more complicated than it is. Let's look at a simple example: /(w|c)ould/g.

Notice how there's a special match on the first letter. We have essentially picked out the small part of the string we care about: the first letter of an 'ould' sounding word.

We can use a second group to match 'wood', too, with an or in the middle of the regex: /(w|c)(oul|oo)d/g

What else would this regex match that is not in this string? I'll leave this as an exercise to the reader.

How Many Times? Regex Quantifiers

If we care how many times a regex factor occurs, meaning characters, groups, and classes (up next), we can use a quantifier. Quantifiers come in two formats: ranges between curly braces and the special characters *, +, and ?.

Let's talk about ranges first. Google owns a number of variations on the domain 'google.com' with varying numbers of 'o's. The following domains will all take you to Google: gogle.com, google.com, gooogle.com. We can capture any of these variations using a range quantifier: /go{1,3}gle/g.

It turns out, they also own the domain with 5 o's, but a squatter owns the domain with 4. So, we can put together the three big concepts we've learned so far: choices, groups, and quantifiers, to "match g followed by 1 to 3 o's or 5 o's followed by 'gle'" with this regex: /g(o{1,3}|o{5})gle/g.

Ranges in the form of {N,} that do not have a ceiling translate to "at least N times". We can use quantifiers on groups, too, so we can find all instances of the google domain with an even number of o's like this: /g(oo){1,}gle.com/g

Now we're ready to start talking about the special quantifier characters. They're simple shortcuts for commonly used ranges:

* is {0,} - 0 or more matches
? is {0,1} - 0 or 1 match
+ is {1,} - 1 or more matches

Thus, the previous example could have also been written as /g(oo)+gle.com/g

Regex Character Classes

We saw how we could match a 'w' or a 'c' using a group and a choice with (w|c). What if we wanted to match all vowels? /(a|e|i|o|u)/g. That's starting to get verbose!

There is a special construct in regular expressions called character classes, they are placed within square brackets []. For example, /[aeiou]/g and /(a|e|i|o|u)/g mean roughly the same thing. Ranges can be used, too, so [A-Z] is all uppercase English letters, [a-z] is all lowercase letters and [A-Za-z] all english letters. Finally, classes can be complemented with the ^ character to say "not any of these characters" so consonants could be described as the opposite of vowels: /[^aeiou]/g. (Note: Complements include all ASCII characters so [^aeiou] includes numbers, punctuation, etc.)

We can match words using a class of all English characters and a 1 or more quantifier, /[A-Za-z]+/g, such as:

Pulling it All Together

As a last example let's put all the concepts we've covered in regular expressions together to pick out tags from an HTML file. HTML tags open like <div id="container"> and close like </h1>

Let's focus on finding opening tags, for now. They start with a less than sign and are followed by a letter, followed 0 or more other letters or numbers. We'll use a capturing group to pick out the important part: /<([A-Za-z][A-Za-z0-9]*)/g

What if we wanted to pick out the attributes of a tag, too? We could match everything except the greater than character, using a complemented character class: ([^>]*)

As a final touch we can also match all closing tags, too. The difference between a closing tag and an opening tag is forward slash after the greater than sign like </ that. The slash can occur 0 or 1 times, 0 for opening, 1 for closing. The forward slash is a special regex character so it must be escaped with a backslash. We'll cover escaping special characters in a future post, for now just take my word that if you use \\/ it means simply a forward slash. So, this last little piece looks like (\\/?) and our product is /<(\\/?)([A-Za-z][A-Za-z0-9]*)/g

That's all for now, folks. We've seen how regular expressions can be used in the most basic sense as similar to your text editor's "find", covered choices which allow for ORs in our matching, used groups to pick out the important parts of a match, looked at sequences giving us the ability to specify how many times a match occurs, and finally poked around with character classes for concise lists of characters that match or do not match. Armed with just these tools you've got 80% of the power of regular expressions under your belt.

Unfortunately the other 20% of regular expression syntax is more detail oriented. These topics include special characters & escape codes, anchors, non-capturing groups, and lazy vs. greedy matching. We'll be covering these topics in future posts in this series. If you're eager to learn regular expressions you should subscribe to our development blog and continue playing around with our free regex tester.

Getting content from a remote server using Smarty

Thu, 22 Oct 2009 16:35:00 EDT

Although our CMS is designed to handle most of the requirements of our clients, occasionally we find ourselves needing to include information that is stored in another system. One such project (the details of which I can't reveal yet) was just such a case. The client has a legacy e-commerce and CRM system running on a Windows server, which they are tied to for various reasons.

Ideally, we would interact with the remote app by using public APIs to fetch data and do any processing and formatting on our server before outputting it in a Smarty template. This particular system, however, does not provide an API.

Fortunately, PHP provides several ways to get the text of a remote file and manipulate it as you would any other content. The easiest of these methods, and the one we decided to use, is file_get_contents. Given the name of a file, this function returns its entire contents as a string, easy as that. Now we can just output that string into the content area of our template, surrounded by the same header, footer, and navigation as the other pages on the site.

Is It Really That Easy?

Unfortunately, there are a few caveats. The first is that you either need to have access to the templating system of the app you are pulling from—so you can remove everything but the actual content—or you will need an HTML parser to pull out the section you want to use. Dropping an entire html page into your template will give you a huge mess, as you will have duplicate <html>, <head>, and <body> tags, which is most definitely not allowed.

The second issue is that any relative urls in image or link tags will now be broken. We are using a regular expression (created using our handy new RegEx Tester!) to find all the relative urls and replace them with absolute urls pointing back to the original server.

Smarty Plugin

I have wrapped this whole process up in a Smarty plugin. Just download the plugin file and drop it into the plugins folder inside your copy of Smarty. There is no configuration or installation: you're ready to go.

Usage

{get_remote url="http://www.test.com/page.html" [default="Text to show if the file isn't found"] [fix="href|src"]}

Parameters

url: The remote url to fetch. This is the only required parameter.
default: Text to be shown if the remote file couldn't be found or if no url is passed in. Defaults to "Not found".
fix: Pipe-delimited list of html attributes that will have their contents checked for relative urls. Defaults to "href|src|action".

Warnings!

Smarty evaluates PHP code that is included this way! Generally, this shouldn't be a problem, since the remote server will have already processed the php code and given you the results. However there is the potential for serious security issues here if, for instance, the remote server doesn't have PHP enabled and gives you the raw source code. If you don't trust the remote server, you probably shouldn't be using this plugin.

This is a beta release. There are likely still bugs in it. If you find any, please report them in the comments.

What is still to do?

Caching is the main thing. I plan to add that capability within the next few weeks. I would also like to implement more flexible url replacements at some point (i.e. not just in html attributes), but that is a fairly complex problem.

Free Regular Expression Tool for Writing and Testing RegExps

Wed, 21 Oct 2009 11:10:00 EDT

You know the green-on-black code flying all over the computer screens in The Matrix? Regular Expressions don't look too different. They can be really gnarly and debugging them is a pain. This is why we created a free Regular Expression tool to help learn, author, and test RegExps.

Regular Expressions are a powerful way of programmatically searching for and replacing text. They're used in a wide variety of ways. Some examples include validating inputs to ensure a user has provided a valid phone number and email address, finding all links to external websites on a web page, extracting content from one website to another, etc.

I will be using the HiFi RegExp Tool in an upcoming blog post series on "Getting Comfortable with Regular Expressions". You should subscribe to our development blog to receive updates on this series as they come.

How to create a blog with the Recess PHP Framework, Part 2

Fri, 16 Oct 2009 10:45:00 EDT

This is the second article in my Recess PHP Framework blog tutorial. The previous article demonstrates how to setup a basic blog that lists posts with links to individual posts. This tutorial will demonstrate how to create, update, and delete blog posts. The code in this tutorial picks up where the previous tutorial left off. If necessary, you can download the completed tutorial 1 code before reading further.

Creating posts

We require two controller actions to create a post. First, we need a PostsController::write() action to display an HTML form. This form will submit to the PostsController::create() action that will insert the new post into the database.

First, create the PostsController::write() action using this code:

/** !Route GET, posts/write */
public function write(){
    $this->post = new Post();
}

Line 1: We can access this action with a GET request to [BLOG_URL]index.php/blog/posts/write
Line 3: We provide a new empty Post to our view template

Let’s create the template for this controller action. Create [BLOG_ROOT]views/home/write.html.php. Open this file in a text editor and insert the following markup:

<html>
<body>
    <h1>Write Post</h1>
    <form action="<?php echo Url::action('PostsController::create'); ?>" method="POST">
        <fieldset>
            <label for="title">Title</label><br/>
            <input type="text" id="title" name="post[title]" value=""/><br/>    
            <label for="content">Content</label><br/>
            <textarea id="content" name="post[content]" rows="20" cols="50"></textarea><br/>
            <input type="submit" value="Create Post"/>
        </fieldset>
    </form>
</body>
</html>

View the PostsController::write() action in a web browser at [BLOG_URL]index.php/blog/posts/write/. You should see an error. This is expected, because we have not yet created the PostsController::create() action which must exist since we reference this action with the Url helper in the PostsController::write() template. Let’s do that now.

Create the PostsController::create() action using this code:

/** !Route POST, posts */
public function create(){
    $post = new Post($this->request->post['post']);

    if( $post->save() ){
        return $this->redirect($this->urlTo('listPosts'));
    } else {
        return $this->ok('write');
    }
}

Line 1: We can access this action with a POST request to [BLOG_URL]index.php/blog/posts
Line 3: We instantiate a new post with data passed from our form
Line 5: We attempt to save the new post to the database
Line 6: If post saves, redirect to the PostsController::listPosts() action
Line 8: If post does not save, render the PostsController::write() template

There are several new features introduced in this action. First, we utilize the $this->request object. Every Recess controller provides easy access to the current request via $this->request. If you print_r($this->request); in a controller, you can see all of the information available. In the PostsController::create() action, we access a POST variable from $this->request->post, an array of all POST variables in the current request. Similarly, you could also access GET or PUT variables with $this->request->get['variable_name'] or $this->request->put['variable_name'], respectively.

We also use a controller helper method called $this->urlTo('action_name');. This helper method returns the full URL to a controller action, useful for redirects, etc, within a controller. Why not just hard-code a URL? Because routing information may change even if the controller actions do not (keep in mind this is a modular blog application that may be shared among Recess installations). This controller helper method allows us to maintain redirects while respecting controller action and route decoupling.

Before you try to create a new post, there is one small caveat. Currently, Recess requires you to create a template for every controller action, even if a template is not needed. So, go ahead and create an empty file at [BLOG_ROOT]views/home/create.html.php. The Recess developers are aware of this issue and will remedy this in a future update. Also, Recess does not yet have a “Flash” messaging feature similar to Rails or CakePHP. If you need to display a message to users, you will need to set a controller instance variable ($this->flash) before rendering a template; you can then check if this variable exists in the template and render a message if necessary.

Now you can create a new post at [BLOG_URL]index.php/blog/posts/write. When you submit the form, you should be redirected to the listing page and see your new post in the list.

Editing posts

We also need two controller actions to edit a post; the PostsController::edit() action will display an HTML form populated with the current post’s details; the PostsController::update() action will update a post in the database with details passed from the HTML form.

First, create the PostsController::edit() action with this code:

/** !Route GET, posts/$id/edit */
public function edit($id){
    $post = new Post($id);

    if( $post->exists() ){
        $this->post = $post->find()->first();
    } else {
        return $this->redirect($this->urlTo('listPosts'));
    }
}

Line 1: We can access this action with a GET request to [BLOG_URL]index.php/blog/posts/1/edit
Line 2: We pass the dynamic route $id parameter into the action
Line 3: We instantiate a Post with the specified ID
Line 5: We check to see if the Post with the specified ID exists
Line 6: If post exists, we pass the Post to the template
Line 8: If post does not exist, we redirect to the listing view

Let’s now create the template for this action. Create [BLOG_ROOT]views/home/edit.html.php and insert the following markup:

<html>
<body>
    <h1>Update Post</h1>
    <form action="<?php echo Url::action('PostsController::update',$post->id); ?>" method="POST">
        <fieldset>
            <label for="title">Title</label><br/>
            <input type="text" id="title" name="post[title]" value="<?php echo $post->title; ?>"/><br/>    
            <label for="content">Content</label><br/>
            <textarea id="content" name="post[content]" rows="20" cols="50"><?php echo $post->content; ?></textarea><br/>
            <input type="hidden" name="_METHOD" value="PUT"/>
            <input type="submit" value="Update Post"/>
        </fieldset>
    </form>
</body>
</html>

This markup is very similar to the write HTML form, but there are subtle differences. First, the form action is different, pointing to the PostsController::update() action instead of the PostsController::write() action. Second, although the form’s method is technically “POST”, we override this method using a hidden field with name “_METHOD” (the leading underscore and capitalization are important) and value “PUT” (capitalization is important). When Recess receives this POST request, it will treat it like a PUT request. We will cover this concept more in a later tutorial about RESTful routing in Recess.

We can now view this action in web browser at [BLOG_URL]index.php/blog/posts/1/edit; however, we receive an error. Because we reference the PostsController::update() action with the Url view helper, we must first create the PostsController::update() action. Let’s do that now.

Create the PostsController::update() action with this code:

/** !Route PUT, posts/$id */
public function update($id){
    $post = new Post($id);

    if( $post->exists() ){
        $this->post = $post->find()->first()->copy($this->request->put['post']);
        if( $this->post->save() ){
            //set a success message if necessary
        }
        return $this->redirect($this->urlTo('edit',$id));
    } else {
        return $this->redirect($this->urlTo('listPosts'));
    }
}

Line 1: We can access this action with a PUT request to [BLOG_URL]index.php/blog/posts/1
Line 2: We pass the dynamic route $id parameter into the action
Line 3: We instantiate a post with the specified ID
Line 5: We check to see if the post with the specified ID exists
Line 6: If post exists, we copy the new form data into the post
Line 7: We attempt to save the post
Line 10: We redirect back to the post’s edit form
Line 12: If post does not exist, we redirect to the listing view

As I explained above, Recess currently requires a template for every controller action, even if a template is not needed. Create an empty template file at [BLOG_ROOT]views/home/update.html.php.

Now you can view [BLOG_URL]index.php/blog/posts/1/edit in a web browser. You should see an HTML form populated with the specified post’s details. If you edit the details and click the ‘Update Post’ button, you will see the same edit form with the new details.

Deleting posts

We only need one additional action to delete posts. Create the PostsController::delete() action with this code:

/**
 * !Route DELETE, posts/$id
 * !Route GET, posts/$id/delete
 */
public function delete($id){
    $post = new Post($id);

    if( $post->exists() ) $post->delete();
    return $this->redirect($this->urlTo('listPosts'));
}

Line 2: We can access this action with a DELETE request to [BLOG_URL]index.php/blog/posts/1
Line 3: We can access this action with a GET request to [BLOG_URL]index.php/blog/posts/1/delete
Line 5: We pass the dynamic route $id parameter into the action
Line 6: We instantiate a post with the specified ID
Line 8: We delete the post if it exists
Line 9: We redirect back to the listing view

The only new feature with this action is that we use multiple routes. I have added the GET route only for convenience. Although this action does not require a template, Recess requires a blank template at [BLOG_ROOT]views/home/delete.html.php to avoid an error.

Finally, let’s add “Edit” and “Delete” links to the PostsController::listPosts() template for convenience. Update [BLOG_ROOT]views/home/listPosts.html.php to read:

<html>
    <body>
        <h1>Posts</h1>
        <ul>
            <?php foreach( $posts as $post ): ?>
            <li>
                <h2><a href="<?php echo Url::action('PostsController::show',$post->id); ?>"><?php echo $post->title; ?></a></h2>
                <p>Posted on <?php echo strftime("%B %e, %Y", $post->created); ?></p>
                <p><?php echo $post->content; ?></p>
                <p>
                    <a href="<?php echo Url::action('PostsController::edit',$post->id); ?>">Edit</a>
                    <a href="<?php echo Url::action('PostsController::delete',$post->id); ?>" onclick="return confirm('Are you sure?');">Delete</a>
                </p>
            </li>
            <?php endforeach; ?>
        </ul>
    </body>
</html>

Now when you view [BLOG_URL]index.php/blog/posts in a web browser, you can click “Edit” or “Delete” beside each post to edit or remove the post.

In summary

This article demonstrates how to create CRUD (create, update, and delete) actions in the posts controller. You can now view [BLOG_URL]index.php/blog/posts/ in a web browser to view posts, create posts, edit posts, and delete posts. The next article in this series will explore model relationships by adding comments and tags to our blog posts. Stay tuned!

Download the final project

This file contains the Recess Framework and all controllers, models, and views for this tutorial.

Download (ZIP, 342 KB)

nmcDropDown: A Drop-Down Menu Plugin for jQuery

Wed, 14 Oct 2009 14:00:00 EDT

In my post on using template site to save time, I included a quick jQuery plugin for creating drop-down menus. Although that code has served me well I thought it was time to revisit it and make it more flexible and bullet-proof. This is the updated version that I will be including in my blank site template going forward

I found that I was still having to modify my plugin code to accomodate variations in interaction design. Since I sometimes wanted the menus to only appear whe n the y are clicked—rather than on hover—now that is an option. Also, when the top-level menu items are smaller (or when the sub-menus fly out from the side) the usability can be vastly increased by Brian Cherne's wonderful hoverIntent plugin. HoverIntent keeps the sub-menu from disappearing if your pointer leaves the edge for a split-second. This version will use hoverIntent automatically if you have it; otherwise it will revert to the standard hover event. I recommend copying the minified version of hoverIntent into the bottom of your main JavaScript file. It is quite small and including it in your main file will save an http request and speed up your page loading time.

Usage

You should create your navigation as a nested unordered list. Linking the top-level items is optional and will not change the working of the plugin. You should style your menu first with css. How you do that is up to you, but you should set the sub-menus to display: none (this is actually optional, but will prevent the sub-menus from flashing on page-load).

<ul id="nav">
    <li>About
        <ul>
            <li><a href="#">Profile</a></li>
            <li><a href="#">Board of Directors</a></li>
            <li><a href="#">Contact Info</a></li>
        </ul>
    </li>
    <li><a href="#">Products</a>
        <ul>
            <li><a href="#">Widgets</a></li>
            <li><a href="#">Doohickeys</a></li>
            <li><a href="#">Thing-a-ma-bobs</a></li>
        </ul>
    </li>
</ul>

The nmcDropDown plugin comes with sensible defaults, so you can just call it on the <ul> element that contains your navigation. The plugin will check each menu item to see if it has a sub-menu and set it up as a drop-down if it does.

$('#nav').nmcDropDown();

Configuration

If you want more control over the way your menu works, there are a number of configuration options available to you. Pass an object containing any that you want to change in as the first parameter of the nmcDropDown() call.

$('#nav').nmcDropDown({trigger: 'click'});

Available Options:

trigger: Event on which to show or hide the sub-menu, can be 'hover' or 'click'. ('hover')
active_class: Class to give open menu items, useful for styling. ('open')
submenu_selector: The element immediately below the top-level list-items containing the sub-menu. ('ul')
show: Effect(s) to use when showing the sub-menu. ({opacity: 'show'})
show_speed: Speed of the show transition. (300)
show_delay: Delay before the sub-menu is shown (requires HoverIntent). (50)
hide: Effect(s) to use when hiding the sub-menu. ({opacity: 'hide'})
hide_speed: Speed of the hide transition. (200)
hide_delay: Delay before the sub-menu is hidden (requires HoverIntent). (50)
fix_IE: This will attempt to fix IE 6 and 7's problems with z-index, where the sub-menu appears behind the body of the page. Set to false if it is interfering with your other styling. (true)

Example

We recently launched a website for North Carolina Business Opportunity and Workforce Development, a program that helps women, minorities, and small businesses secure NCDOT contracts. I created drop-down menus that use the nmcDropDown plugin with custom show and hide animations for an interesting effect. The show animation is {opacity: 'show', top: '-=10px'} (hide is exactly the reverse), which fades the menu in while sliding it up from below.

Update: I have also created and written up an example of how to use nmcDropDown, including HTML and CSS.

Download

Full, commented version (3.5kb)

Minified version (1.3kb)