Way back when CakePHP had a wiki there were a series of articles on “Advanced Validation.” One aspect of these articles was using the Model rules in JavaScript to validate on the client side. The code (I believe this is it) was originally for CakePHP version .10 (iirc). I had been using a heavily modified version of this code even in my 1.2 projects, but it was due for a ground up re-write.

I wrote an article for PHPArch not too long ago with a generic PHP approach for JavaScript validation. Using that JavaScript as a base, I created a helper to convert the model rules into JavaScript.

Here are the links:
Download
Instructions
Demo

This is all very beta, so please let me know if you find an issue. The helper should work with the three formats for defining validation in your model (output from bake, one rule per field, multiple rules per field).

If you are worried about security, there is an option to only include certain rules. See the tips section at the end of the instructions. Thanks to Marc for suggesting this.

Popularity: 96% [?]

I just posted a bug fix for my CakePHP Asset Packer. The previous version didn’t handle $javascript->codeBlock, when the inline option was set to false. The JavaScript would just disappear…ooops. Updated code is available in the Bakery article or you can download here.

Popularity: 80% [?]

I just stumbled on this smokin’ article on PHP Architect’s new C7Y site. It’s really some of the best PHP writing I’ve ever seen - even non-programmers will probably enjoy it…uh…alright I wrote. So please check it out.

I’m about 75% done rolling this into a CakePHP helper. And since Cake is going re-focus on jQuery as it’s primary JavaScript library there will be no excuse for not using it.

Popularity: 85% [?]

I almost never post links to other blogs posts, but I thought this was cool.

Leon Chevalier from AcidDrop.com (is this the worst name for a blog designed to showcase one’s professional skills or just in the top 5?) has created a PHP class (latest version) that will automatically package and minify all your CSS and JS.

I was playing around with it to see if there was anything extra Leon was doing that my CakePHP Asset Packer wasn’t. One thing I found interesting is that the actual cached CSS and JS are stored as PHP files. This is done so that PHP can set the expires headers and gzip the contents. Granted this should/could be done with the actual web server, but many shared hosts don’t allow this. Even so I’m not really sure doing this is a great idea, since you’re essentially trading process time for network time.

From the comments it seems like people are having success using this with their WordPress sites. It would make sense to roll the whole thing into a plugin.

Popularity: 80% [?]

R. Rajesh Jeba Anbiah left a comment concerned about the performance hit when using the CakePHP Asset Packer Helper.

The major reason for choosing the Asset Helper is to speed up the site. But, the hit on the helper call is heavy–at least for me. [snip] …for the real benefit, one seems need to manually minify/pack.

I decided to put this to the test. I grabbed a fresh download of the latest CakePHP 1.2-beta and made a basic TestsController with one action with a view. It didn’t use a model. I took the default layout and moved it to my /app/views/layouts. In the layout I added 2 Stylesheets and 2 JavaScripts. In the view I included one of each using the $scripts_for_layout method. I used ab, with the parameters “-c 10 -t 60″, to do the testing. Since this was all on my local machine network speed isn’t really a factor. Essentially I would be getting the times to render the page.

The first test I ran was without the Asset Packer Helper - what you would get with the base CakePHP install.
Here’s the baseline results:
Complete requests: 622
Requests per second: 10.36 [#/sec] (mean)

The hope is that including the helper won’t hurt these numbers too much. The speed increase gained by using the helper is seen in the download of merged js and css files and since ab is only testing the html file (not the images, css, jss linked within), the benefit of the helper won’t be evident in this test.

First I included the helper and commented out the filecaching. This is essentially what happens when the helper is being used for the first time on a particular group of css/js files. Either because one of the files has changed or because the cache hasn’t been created yet. Consider this to be the worst case scenario and probably would only really happen a tiny percentage of the time, like right after you do an update. I expected the numbers to take a hit, but not to be this bad:
Complete requests: 32
Requests per second: 0.52 [#/sec] (mean)

Did I emphasize that this scenario doesn’t happen very often? I could try to improve this, but I’m not sure it’s worth it. This doesn’t happen too ofter, plus most of the time is probably in the css and js minifying/packing, which are vendor classes.

Let’s take a look at a more common use case. The cached files already exist, so the helper checks to see if there are any changes, finds none and doesn’t have to do any extra processing.
Complete requests: 583
Requests per second: 9.69 [#/sec] (mean)

Much better. Still a hit from the baseline numbers, but not too bad.

Here’s one more test. In the AssetHelper class there is a var $checkTS. Setting this to false will disable the functionality described above, where the helper will see if any of the original css/js have changed and the cached version needs to be rebuilt. You can safely set this to false if you clean out your packed directories with new builds.
Complete requests: 602
Requests per second: 10.03 [#/sec] (mean)

That’s an improvement over the default settings for the helper and are pretty close to the baseline results. The difference is 3.15700 milliseconds/request or .003157 in seconds.

I may look into trying to get that last scenario closer to the baseline, but the difference isn’t so significant that I would really worry about it.

So what does the extra .003157 seconds of processing time get you? This isn’t a perfect test, but I ran Yslow on the baseline setup and again with the helper. The baseline scored a D(61). With the helper that jumped to a B(81).

Popularity: 92% [?]

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.

Popularity: 62% [?]

One of my goals with this blog is to post more code snippets. It is something I did occasionally on my old blog. It’s one of those things that should be simple, but ends up being a bit of a pain. I’ve used a Wordpress plugin in the past, but I was never fully satisfied with it. Lately I’ve seen some other programming blogs I read using a client side Javascript solution. After some digging the two “ready for prime time” packages I found were Chili and SyntaxHighlighter.

This is a comparison of those two. If you feel I missed another package let me know in the comments.

Chili

License: MIT
Includes: jQuery(21KB), core (7KB), PHP CSS(1KB), PHP JS (37KB)

One of the things I initially liked about this package was that it used jQuery, which is my new favorite Javascript library, although then I realized, as much as I use jQuery on my web apps, I don’t really have a need for it on this blog. So having to include it was just additional baggage.

I’m not crazy about the overall size. The PHP “recipe” is 37KB alone. Much bigger than any of the others. Another drawback is the weak documentation. The Chili page is long, dominated by the change log - which is good information, but placed poorly. A simple “how to use Chili” section with code samples - USING THE FREAKING PACKAGE would be nice [Update July 24, 2007 - Chili has a new quickstart page. I'll leave me rant here for entertainment purposes].

You know, something like:

1) Include jQuery and the Chili Javascript files. Your paths may be different.

<script type="text/javascript" src="/js/jquery.js"></script>
<script type="text/JavaScript" src="/js/chili-1.8b.pack.js"></script>

2) Chili can automatically find the recipes it needs - simply tell it where to look.

<script id="setup" type="text/javascript">
    ChiliBook.automatic = true;
    ChiliBook.recipeFolder     = "chili/js/";
    ChiliBook.stylesheetFolder = "chili/css/";
</script>

3) Wrap your code and tell Chili which recipe to use. Remember to replace & with &amp; < with &lt; and > with &gt;

<pre><code class="php">
<?php
    class family_friendly() {
        function censor($word) {
            return '*' . gettext($word) . '*';
        }
    }

    function get_license() {
        return 'Creative Commons';
    }

    printf('This guide is released under the %s license.<br />', get_license());
    printf('Seriously, Chili author, if you are reading this, move 95% of the %s onto secondary pages and include this simple tutorial.<br />', family_friendly::censor("crap"));
?>
</code></pre>

That’s all you need. Thats all the information 99% of your users need. I shouldn’t have to figure out which of the five example pages I need to view source on to get this working. Especially when they have such confusing names as: examples-all-combinations.html (which appears to be a joke, that I don’t get), examples-dynamic-automatic-adhoc.html, examples-dynamic-automatic-adhoc-metaobjects.html, examples-static-automatic-adhoc.html. Huh?

I’m done with my rant. I’ll say some nice things about Chili now. One of the features that is really cool is that it’s completely automated. You simply wrap your code with the correct tag and Chili does the rest. Also since it is a plugin for jQuery it degrades nicely, leaving the code less pretty, but still completely readable.

Now that I said something nice I can go back to ranting. The samples provided with the download have Google Ads in them. I can understand having them on the actual site, but in the downloaded samples it seems a bit tacky to me. Even worse the ads are all food related, that is when they’re actually in English. I assume the author simply took the pages directly from the site and rolled them into the download, but I still find it annoying.

Also the author makes the claim “You just put the code you want highlighted in a code tag AS IS”. Then not even 300px later he states “Always escape the content of the code element for HTML: at least substitute any & by &amp; and any < by &lt; in this order. If you want to highlight HTML you also need to escape any > with &gt;.” So it isn’t exactly “AS IS”.

SyntaxHighlighter

License: GNU
Includes:CSS(4KB), core(11KB), PHP (5KB)

SyntaxHighlighter is obviously a much lighter solution. It too has separate includes for each language, called brushes here. The instruction page is also well done. In addition to highlighting and formatting the code SyntaxHighlighter adds buttons that allow the user to view plain, copy to clipboard and print. On the downside it isn’t automated like Chili, although you could certainly use jQuery, or some custom javascript to execute HighlightAll on a page load. Like Chile you need to encode the < character (but not > or &).

1) Include the core files and the brushes for any language you want. Your paths may be different.

    <script type="text/javascript" src="/syntaxhighlighter/js/shCore.js"></script>
    <script type="text/javascript" src="/syntaxhighlighter/js/shBrushPhp.js"></script>
    <script type="text/javascript" src="/syntaxhighlighter/js/shBrushJScript.js"></script>
    <script type="text/javascript" src="/syntaxhighlighter/js/shBrushXml.js"></script>

2) Put this at the end of your file. If you put it before the code you want highlighted it won’t work.

<script class="javascript">
dp.SyntaxHighlighter.ClipboardSwf = "syntaxhighlighter/js/clipboard.swf";
dp.SyntaxHighlighter.HighlightAll("code");
</script>

3) Wrap your code and tell SyntaxHighlighter which brush to use. Remember to replace < with &lt;

<pre name="code"  class="php">
<?php
    class Highlighters() {
        function result($highlighter) {
            switch ($highlighter) {
               case "chili":
               default:
                  return "FTL";
               case "syntaxhighlighter":
                  return "FTW";
            }
        }
    }

    $highlighters = new Highlighters();
    printf("Chili is a nice effort, but just not for me.  Chili %s", $highlighters->result("chili"));
    printf("I am going to give SyntaxHighlighter a shot.  SyntaxHighlighter %s", $highlighters->result("syntaxhighlighter"));
?>
</pre>

Wrap Up

If you’re already using jQuery and want to highlight non-PHP then Chili is worth checking out. For this blog I’m going to give SyntaxHighlighter a shot. I think end result of SyntaxHighlighter is nicer looking and the additional buttons are useful features.

If you have any experience with either feel free to write about it in the comments.

Popularity: 75% [?]