Integrating JEL

How to include JEL in your site pages.
More information about sizes (builds) available.

Prerequisites

Since JEL is based on both the Prototype library and Dean Edwards' Base library, both of those will need to be downloaded first. The following script tag examples assume they are installed in the /js/lib/ folder, but it can obviously be anything:

<script type="text/javascript" src="/js/lib/base.js"></script> <script type="text/javascript" src="/js/lib/prototype.js"></script>

JEL Builds

The JEL library is available in 3 different download sizes on the home page:

• Jumbo Size: This is a zip package of all of the source files the JEL library is based on. You would not typically use this on either a development or production site, since you'd need to include these files in a specific order to make sure all dependencies are correct. The most likely use for this package is either to study the library source code, or to take just a few functions from it for your own code (this is certainly allowed under the licence).
• Regular Size: This is a single file build of the entire JEL library, with all comments included. This is the best build for a development site, where being able to debug the code in tools like firebug is important.
• Travel Size: This build is an encoded build that's been run through Dean Edwards' Packer tool. This is strongly recommended for a production site, since it is significantly smaller than the other builds.

Assuming you've downloaded the regular size build and placed inside /js/lib/, then your script tags would then look like:

<script type="text/javascript" src="/js/lib/base.js"></script> <script type="text/javascript" src="/js/lib/prototype.js"></script> <script type="text/javascript" src="/js/lib/jel.en.us.js"></script>

The Core Extender

The debate rages on about whether or not JavaScript developers should extend the built-in JavaScript objects for their own (evil) purposes. There seem to be two schools of thought:

• Don't do it at all - leave the JavaScript objects alone, since you may break compatibility with other libraries.
• Extend the objects if you like, but DON'T override any built-in functions and change the core functionality.

Personally, I have no problem with extending the objects, since it can certainly be convenient to do so. Comparing the 2nd and 3rd lines of code below, I know which one I prefer:

var str = "hello" alert(Jel.String.right(Jel.String.trim(str), 3)); // "llo" alert(str.trim().right(3)); // "llo"

JEL takes the diplomatic approach, and allows you to decide if you want to extend the built-in objects or not. This is done via the CoreExtender object - if you wish to extend the core JavaScript objects, and make the more convenient syntax available, simply add the line of code below to your global JavaScript space:

new Jel.CoreExtender();

Note that internally, JEL does NOT assume that the core has been extended, and so favors the more verbose syntax. Please refer to the Jel.CoreExtender API page for more details about how this object works.

Return to manual index