Multiple Repos

I wasn't very smart about this whole Git fad when I first started my GitHub account and just dumped all my CakePHP code into one repo. Turns out this isn't the way to do it, since you have to clone the whole repo, even if you just want one piece of code. My bad. Everything has now been split into it's own repo to make it easier for you guys to fix my shitty code. You're welcome.

jQuery Validation Updated

My jQuery Validation helper has now been pluginized. Actually, it's now a plugin within a plugin. Both the CakePHP helper and the jQuery code are plugins. It's not a straight drop-in for the old version, so make sure you read the directions. Basically it does all the same stuff as before - converts your Cake validation rules from the model to work in JavaScript, where it can. The cool thing about making the JavaScript into a proper jQuery plugin is that you can now add custom handling without changing the original source.

Callbacks

At the moment there are three callbacks: beforeFilter, setError and afterFilter.
beforeFilter - called before validation is started. No params.
afterFilter - called after validation is done. Passed an array of errors.
setError - called anytime a validation error is found. Passed the field and the error message.

So if you wanted some alternate handling for errors you could do something like this:

$.fn.validate.setError = function(field, message) {
  //don't ever do this or I will come for you
  alert(message);
}

Custom Rules

The old version would skip right over the custom validation rules, since it didn't know how to handle them. This new version includes the rules and if a function with the same name exists it uses that to validate. It's up to you to write the custom function and you're free to use Ajax here. For example if you had a custom validation rule "myRule" you would define the function like this:

$.fn.validate.myRule= function(val, params) {
  //do some validation here and return either true or false.
}

params is the same as they are defined in the model's validation.

Model Lazy Loading

My first attempt at this was moderately successful, but some flaws were pointed out in the comments. A commenter also pointed out some code in the CakePHP bin that was attempting to accomplish the same thing. The oldest instance I could find was this one. The were some things I liked about this version, namely it didn't remove the defined associations. But I also didn't like the was it took over the __constructLinkedModel method. After going around and around with this I've come to the conclusion that it's the only way.

I've updated my version to use the same principles as jose_zap's CakePHP bin version. Here's the differences:

• DRYier
• Runs as a plugin
• catch resetAssociations - This is called after a find operation and inadvertently builds all the models, completely defeating the purpose of this code. Basically I'm just removing the functionality, which only matters if you used bindModel. If you're using this code block there really isn't any reason to be using bindModel, so I figure there's no harm here.

This update should fix the issues with counterCache and HABTM inputs.

Coming Up

I plan on rolling pretty much all my code into plugins. It's just so much easier to distribute and keeps everything contained. Keep an eye on my repo if you're interested - I won't be bothering with blog posts for every update.

CLICK TO READ MORE >>>

I wrote a post a few weeks back about how to make a entire element (usually a div) clickable based on one of the links contained within. Having never written a jQuery plugin before I figured this would be a pretty simple one to start with. The code is available in my GitHub repo. Instructions and an example are also included there.

I use this trick a lot. Often I'll have an box with an H tag and an area below it with some detail text. I want to make the whole box clickable based on the link in the H tag. Here's an example of what I'm talking about:

The HTML for this box is simple:

<div class="section">
    <h3><a href="/link/to">Section Title</a></h3>
    <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras non est vel neque ornare porta. Donec convallis. Nam odio felis, euismod quis, molestie sed, auctor quis, purus. Donec eu dolor.</p>
</div>

I'll leave the CSS up to you, but be sure to include at least this section, which forces the link to fill the entire H area:

.section h3 a {
  display: block;
}

Adding this simple jQuery makes the whole area clickable, linking to the same page as set in the H tag.

$(".section").click(function() {
  window.location = $(this).find("h3:first a:first").attr("href");
});

If you want to get fancy you can also add a hover effect:

    $(".section").hover(
      function() {
        $(this).addClass("hover");
        $(this).append('<div class="learn-more">Learn More</div>');
      },
      function() {
        $(this).removeClass("hover");
        $(".learn-more").remove();
      }
    );

The original box above is an example of all this put together.

I used a ton of Jquery for the freelance project I've been working on lately. Included is a bunch of plugins. Although the plugins are great and add a ton of functionality, there are some downsides.

Since plugins can be created by anyone and distributed individually it leads to a mess of javascript includes. At times one plugin will even depend on another adding even more server requests. A revealing YUI post recently discussed the negative performance impact of so many requests.

The obvious solution is to combine the plugins into one file. This shouldn't violate any license since most of the plugins are distributed under the same MIT/GPL dual license as Jquery.

The Server Side Approach

A recent thread on the Jquery Google group discussed doing this in an automated fashion using a server side script. While this can be a great solution, especially if you need a variety of scripts on each page and you cache the generated js file, it is probably a little overkill for 99% of the sites out there. My other concern is with how the browser caches the rendered file on the client PC. Since it isn't calling a .js page (although you could fake it) does the browser know not to make the request every page? Setting the proper headers probably helps alot.

Another thing I noticed is that many of the plugins do not include a minified or packed version. Running the plugin through a packer is pretty simple, whether you do it manually or with an automated script. The thing I don't like about the automated approach is that it removes all comments, including those crediting the original author.

My Solution

What I've been doing is manually running the plugins through Dean Edwards' Packer, which strips out comments and minifies the code. Then I put the minified version in jquery.plugins.js, with the original header. This serves to separate the packed scripts in the single file, as well as give credit to the original author and maybe lead someone back to their site if they want to achieve a similar effect.

An Example

Check out this file to see this practice in action. This file combines three minified plugins, leaving the headers intact and weighs in at 5.35kb.

The Downsides

a) I'm including some plugins in a page that may not need them. I really only do with will small plugins, ones that compress to 1-5k. So if my jquery.plugins.js includes 5 plugins, but only uses 3 on a particular page it isn't a huge hit.

b) The other downside is that if there is an update to the plugin I need to manually re-pack it and put it in the combined file, rather than dropping it into place. It's not something that happens often, but does require some manual effort. I usually keep the original script in the same directory for reference, even if I don't actually use it on the site.