Posts Tagged ‘plugin’

jQuery listSplitter plugin

Monday, February 1st, 2010

A very short post to announce my third  jQuery plugin: listSplitter, which takes a long list of categorised items (where the categories can overlap) and creates a tabbed interface to show only one category at once. I haven’t done a demo yet (well, I have, buthaving teh same old problem transferring to the server as the server runs on UNIX while my laptop is Windows. I recently found out why this causes a problem, but no easy fix has presented itself) so you’ll just half to take my word for it, though before too many months have gone by I will use it as the basis for a new portfolio.

*edit: Here is a demo

And it can be used with jQuery themeroller, i.e. use the tool at jqueryui.com/themeroller, to design how it shoudl look, then after clicking “download theme” make sure you have ‘tabs’ ticked underneath widgets.

My jQuery plugin writing tips

Wednesday, September 2nd, 2009

I’ve now written two jQuery plugins, and have a pretty good idea for a third. As you might expect, I’ve learned quite a few things along the way. When I started there was a lot I didn’t know about javascript and jQuery. There still is, but one thing that struck me is that there are a lot of great tutorials on writing jQuery plugins out there but none of them individually captures all the things that took my plugins from being nice ideas with mediocre implementations to being something I’m proud of.

So here is my definitive combination of them all, together with one or two of my own contributions (a bit scant on detail, but follow the links for more info).

1. Build a good test page

My test page for any given plugin has 3 instances of a type of element the plugin is suppose to effect. eg a list. They are marked up as follows:

<ul class="single" >...</ul>
<ul class="multiple" >...</ul>
<ul class="multiple" >...</ul>

And I run the following script in the document head

$(document).ready(function() {
  $('.single').myPlugin();
  $('.multiple').myPlugin();
});

This will make sure your plugin works when called more than once on a page, and when one instance affects more than one element. For testing your code for speed the same page with various bits of html copied lots of times does the trick.

2. Follow jQuery’s recommended tutorial

It really is very good, and covers most important points. The other items on the list are either little tweaks that I think make the code neater or, in just one or two cases (highlighted in red), things its missed out. Read the tutorial

3. Make sure your plugin won’t conflict with other javascript libraries

The most effective way to do this is to wrap your whole plugin in a function where $ is its parameter, and then call it on jQuery, like so:

(function($) {
  $.fn.pluginName = function(options) { ... };
})(jQuery);

More info

4. Make your plugin’s settings changeable, both when the plugin is called, and by tweaking the default settings

The way to do this is to set up your plugin’s defaults as a JSON which is a public property of the plugin object. So within your plugin add these lines (where options is the name of the JSON passed to the plugin as a parameter).

this.defaults = {parameter:'value', ...};
options = $.extend(defaults,options);

More info

5. Make sure your plugin keeps track of DOM elements effectively

Structure your code as follows in order to make sure your variables are accessible to the right instances of the plugin, but aren’t stored in memory longer than they need to be.

$.fn.pluginName = function(options) {
  var constructor1, constructor2, ...;//elements that are used only when the plugIn is constructing instances of itself at the start and play no role in handling later events;
  return this.each(function() {
     var tracker1, tracker2, ...;//elements that are important for events and other later changes. Also, if your plugin's constructor involves some AJAX it may be best to put all variables in here
     subFunction() {
	//this should always be able to call the variables it needs, in particular access the right DOM elements
     }
  });
};

6. Optimise, opimise, optimise

You never know how demanding the website using your plugin is going to be: how many times is it going to be called on one page; will the dom objects (eg sorting a list of items) it has to handle be a lot bigger than the ones you’ve tested it on. My crossSelect plugin was, I discovered, before version 4/5, really sluggish on lists larger than about 20 items.

So I found a great list of techniques to optimise your code, the most pertinent to writing plugins I have put below:

  • Make sure your optimisations are optimisations

    To keep track of whether your optimisations are having the desired effect, run your plugin on a page full of huge elements for it to process and then use firebug to measure the time it takes.

  • Don’t over-query the DOM

    jQuery is principallya tool for accessing and manipulating the DOM, but it doesn’t pay to do this too often as your code will be a lot quicker if you keep it to a minimum. Techniques for avoiding this include:

    • store DOM elements you know you will have to access a few times in variables (but be careful – see point 5)
    • Add new DOM elements as html, . So instead of
      $('selector').append('<ul>');
      for(i=0;i<limit;i++)
      {
        $('selector > ul').append('<li>'+i-th text+'<li>');
      }

      use

      string = '<ul>';
      for(i=0;i<limit;i++)
      {
        string+='<li>'+i-th text+'<li>';
      }
      $('selector').append(string);

      The improvement in speed of code is astounding.

    • Use contexts. A lot. It will both reduce code size (as shown below) and speed up the code (because jQuery only has to search a subset of the DOM). So instead of
      var theContainer = $('selector');
      $(theContainer).children('ul').children('li').aMethod();

      use

      var theContainer = $('selector');
      $('ul>li', theContainer).aMethod();

And that’s yer lot. Please let me know if you have any comments or suggested additions.

What’s up with wordpress?

Sunday, July 5th, 2009

My old blog was a blogspot blog, and while using blogger to write posts I had very few complaints. But when it came to setting up this blog I plumped for Wordpress, mainly on reputation; wherever I turned I would read phrases along the lines of “while not a full-featured publishing platform, Blogger does offer an impresive, easy-to-use interface for the novice blogger,” and  damn me if I was going to be labelled a novice!

I have, by and large, though, been very impressed with Wordpress. As a front-end developer, I particularly like the fact that it very rarely gets confused about what to do when you do something (eg delete some html which leaves some tags unexpectedly unclosed) that woudl drive Blogger potty. And the new version of the admin interface (from about version 2.6 onwards) is a staggering improvement on the old version and on Blogger.

However it has one irritating feature: it constantly breaks.

Since upgrading I’ve had the wysiwyg text editor break several times (fixed by deleting and then recopying in the wp-includes folder), saving posts broken once (fixed by overwriting thw wp-admin folder), and for a long period of time couldn’t log out of admin (no idea how this is fixed – it just seemed to go away of its own accord). It’s immensely frustrating (though not frustrating enough to cause me to abandon wordpress).

It’s probably a flaw in the wordpress automatic upgrade plugin, but I’m loathe to abandon that too as it takes the pain out of making tea, so to speak. Though I can’t help thinking it may be a false economy as in the end I have to manually overwrite files anyway.

crossSelect jQuery plugin

Wednesday, May 27th, 2009

I thought I should write a short post to say I have written another jQuery plugin, for making multiple select form elements more intuitive to use. It’s called crossSelect, and here is a demo.

One of these days I will make a proper portfolio site/subsite which collects all the stuff I make together.

I will, I will, I will!

fullTextArea jQuery plug-in

Friday, April 17th, 2009

I’ve just written it, and have to provide a homepage for it. will add more details later.

Demo: fulltextarea.html

Current release

jqueryfulltextarea031

Release details:

  • Tidied up and optimised code

Previous versions

Toolbarize incompatible with wordpress 2.7

Monday, March 23rd, 2009

I’ve just spent a  little time adding some useful sounding plug-ins (initially prompted by wanting an effective backlinking plug-in), one of which was the Wordpress Automatic Upgrade plug-in. So, with that installed I finally got around to upgrading wordpress and, to both my delight and dismay, wordpress has changed its admin screens layout since the last version I had (2.3 I think). It’s a much better design, but it does break toolbarize. In fact, it renders it unneccessary as the layout is much more user friendly and screen-space efficient, with scrolling not being no nearly so disruptive to the postying process.

However, it has inspired me to write a plug-in which makes perfect use of screen space by hiding things I very rarely use… or putting them in the footer. I could even make it so users can customise which screen elements are hidden.