The WebApp Wizard Web development made magical

4May/112

jQuery 1.6 and backwards compatibility

jQuery 1.6 just came out, announcing big performance improvements, enhanced animations, and so on. At first, my brain cells were like having a big wild party, thinking about all the good stuff.

And then comes the hangover. Not backwards compatible? Maybe some little obsolete things won't work anymore, after all, that may not be so important.

But no, it is definitely important. And inconsistent, in some (weird) way.

OK, .prop() is born, taking some duty off .attr(). .attr() is for attributes (attributes don't change over time), and .prop() is for properties (they evolve. For example, is you want to retrieve the actual value of an input, you will use .prop(). OK, .val() exists. But just for the example. On the other side, .attr() will return the original value). Ouch, here is the first problematic change. Think about all the code that will break now...

But it's not only about that. They say that if you want to check a checkbox, you will have to use .attr('checked', true) instead of .attr('checked', 'checked'). Nice to see this more convenient way to do it, but... Shouldn't I use .prop('checked', true) instead? Attributes are not supposed to change, right?

So I'm very confused. As a plugin user AND author, what should I do? Shall I upgrade my plugins to support jQuery 1.6? As I use my own plugins (no? Really?), that would mean I'll have to upgrade my applications to jQuery 1.6 (no, I won't use a deprecated version of my own plugins. I use them in their last version). But if I do so, I'll probably break a good part of the plugins I'm using. If I don't, people who switched to jQuery 1.6 or newcomers probably won't be able to use my plugins. I don't like this.

Let's say I decide to upgrade my plugins. What should I do for the other plugins I use? Wait their respective authors to upgrade too? What if they don't? I could patch them myself, but I don't want to spend hours understanding how several plugins work. And that's without thinking about testing...

So, as an author or as a user, what do you plan to do regarding this good but non compatible version?

EDIT: Well, it seems that they changed their minds. jQuery 1.6.1 is out, with a fixed .attr() method which should be backwards compatible. Follow the story.

15Feb/114

Form submit confirmation, fast and easy

Following some demands, I recently released a new version of Fast Confirm, to make it more easy to implement when dealing, among others, with form submission.

But in the hurry, I forgot to include some features that I developed earlier, thinking "I'll put that online soon". And I didn't. So here there are, the missing features that some of you wanted. With version 2.1.0, you can now tell your confirm boxes that you want them to be unique, just by setting a boolean on invocation.

There is another little thing that I wanted to introduce alongside with the better event handling. Since version 2.0.0, you can simply bind FC to a form submit event, with the "eventToBind" parameter. There is a little problem with that.

Typically, a form will look like :

<form action="action.php" method="post">
   Username: <input type="text" name="username" />
   Email: <input type="text" name="email" />
   <input type="submit" value="Create user" />
</form>

So what happens when the confirm box opens? It opens pointing on the form. That makes no sense. A form is usually not a visual element. You will more likely want the confirm box to be opened on the submit button, or maybe on a fieldset, or even on a input field. But directly on the form tag? No way. Or at least, that would not be very frequent.

So I added the "targetElement" parameter. It simply is a selector that allows you to specify on which element, within the form, you want the confirm box to open. For example, a ":submit" selector will simply make the confirm box open on the submit button of the binded form.

Have a look at the demos!

23Jan/111

Fast Confirm, Universal Paginate, reloaded

Hi everyone.

I finally had some time to re-work on my web projects. Since FastConfirm has been quite appreciated, I decided to take a few minutes to rewrite it a bit. The main concerns were about events management and manipulating it programmatically.

So I decided to take it directly to version 2.0, breaking some backward compatibility. Nothing bad, the usage remains almost the same, except for the "close" method.

So now, you can call:

$('.click_me').fastConfirm('close');

To close the previously opened confirm box.

OK, so this was for the method calling stuff.

You can also now completely delegate event handling to FastConfirm. This feature has been asked for several times, and I must admit I was not really satisfied with the previous plugin usage (well, in fact, you can still use the plugin like you did before). This is mainly useful for form submit confirmation. So now, you can simply do:

$('.confirmable_form').fastConfirm({
   eventToBind: 'submit'
});

And FastConfirm will take care of binding the confirm box on the submit event, allowing it if the user says "yes", canceling it if the user says "no". The same could be true with any event. The new eventToBind parameter defaults to false, which will result on the same behavior than before.

As a reminder, you previously had to write something like this to achieve the same behavior:

$('.button').click(function() {
   $(this).fastConfirm({
      onProceed: function($trigger) {
         $trigger.closest('form').submit();
      }
   });
   return false;
});

That's amazing. But there's one more thing ©. ;-)

The user is now able to close the confirm box by hitting the Escape key. This is the same as clicking "No" and provides a quicker way for the power user. A little detail can sometimes greatly improve the user experience.

I hope you will like this new, rewrote, cleaner and easier version of Fast Confirm. As usual, you can find it here.

Universal Paginate has also been rewrote in order to provide a better control over plugin internals. Methods can now be called the standard way:

$(list).universalPaginate('changeItemTemplate', newItemTemplate); 

for example.

Also, Universal Paginate has a new parameter which overrides ajax requests defaults when querying the server for data on page changes.

As this is the official jQuery plugin authoring recommendations, this rewriting will happen for other plugins, too. It will provide a better consistency and probably less bugs / shitty code.

Oh, and, by the way, these two plugins now pass JSLint. :-)

Last thing, I am very thankful to all of those who contributed to make we want to improve my work, whether with bits of code or simply with comments and requests.

2Nov/100

A new way to paginate

Hi.

Just a little post to tell you I released a new jQuery plugin, Universal Paginate.

It simply allows you to paginate any content, and is not limited to a type of list or table. You want to paginate simple paragraphs? Universal Paginate is here for you. A table? UP is here for you too! Any kind of list (dl, ul, ol)? UP is here, again.

It supports natively some advanced features like remote Ajax JSON datasources, jQuery Templates syntax, on-the-fly changing of the number of elements to display on one page, etc.

Check it out!

4Oct/100

Even lighter and prettier confirmation

Hi all.

I took advantage of working on a little Fast Confirm bug to enhance a bit the user experience. Facing my little confirm boxes, I told myself: these boxes don't stand out as much as they should. Don't disturb the user is nice, but we want him to answer anyway.

So I decided to use a few CSS3 features to make them a bit prettier, a bit more distinct from the rest of the page. So I added a shadow under the box and gave the buttons some color and depth.
I also wanted to get rid of the images I used to make the little arrows on the boxes. So I used some border techniques to achieve that.

The boxes looked like this before:

And now:

I hope you will have a nice time using it.

21Sep/102

How to ask politely the user

When working on a project, you often have to ask the user for information: choice, confirmation, etc. There are a few ways to achieve this: plain old confirm(), prompt(), or fancy dialog boxes (jQueryUI for example), or "inline" stuff.

After having tested Producteev for a while, I found out that I really like the "inline" way. So I decided to do it this way on my current project. I needed an easy, unobtrusive way of asking the user for confirmation. I didn't want to spend hours developing or debugging it, so I came out with this simple plugin: Fast Confirm. It allows you to ask simply and politely the user, without throwing a modal dialog box  in his face. Also, it clearly identifies the source of the confirmation so that there is no doubt what you're talking about.

As usual, there is a tiny demo page to show you how the plugin behaves on a simple use case. Feel free to try it out, download and play with it!

15Sep/100

The forgotten jQuery methods

jQuery is great, jQuery is fast, jQuery is the best JS library, etc. But what if it was more awesome than we think? Personally, I went through that, and I wanted to share.
At the beginning, like most other web developers, I discovered jQuery with very basic features, and, over time, I discovered new ones. One day, I decided to really go through the documentation to see if I could find shortcuts for what I do on a daily basis.
The problem is that we try to solve problems with the tools we know well. But sometimes, we could do a lot better with a new, stronger, sharper tool. That's what I am talking about here. The need to keep up to date, and always try new tools.

2Sep/100

jQuery plugins I never (OK, rarely) code without

Yes, another "X essential jQuery plugins". But this one focuses on utilities that will make your life easier, and not necessarily the user's one. It's not about shinny UIs here, but just about useful utilities. From time to time, it's also good to think about ourselves. :-)

Well, no more talking, let's go straight to the point.

Livequery

Definitely a must-have. Ever had to re-bind some event handlers when doing dynamic DOM injection? Well, throw away your aspirin and download this plugin. It will save you some time, headaches, and performance. I can already hear: "why not simply using jQuery.live()?". Because Livequery supports a larger number of event types (but it tends to be less and less true) and allows to bind handlers on element creation and removal as well.

ClassLike

Ever wanted to store some data on DOM elements? Well, there is jQuery.data() when you want to attach data to your DOM elements from your JS code. For all other cases, there is ClassLike. ClassLike allows you to easily match and retrieve parts of classnames with regexps. You could have, for example, elements wearing the class "colnumber-X" where X is a number. And you want to get this number out of the classname. Well, ClassLike does it for you with a simple regexp.

jTemplates

jTemplates is not the kind of plugin you will need in every project, but it is still so useful that it deserved his place here. Basically, it's like Smarty, but in JS. Very useful for writing widgets, with live refreshing for example.

Form

How can I not mention the Form plugin? It simply allows you to control your form submissions, do some verifications before submitting, and more.

jQueryUI

Quite a heavy plugin, but really useful, from animations to advanced controls, dialogs, sliders... A must-have too. I won't go any further with this one, everybody knows about it.

Of course, there is no need to blindly add these plugins to your pages, but I think they solve frequent problems, and they deserve, at least, a try. You may just love them. :-)

30Aug/100

Sliding Panel v1.2.0

I just released a new version of Sliding Panel, to allow more positioning possibilities.

Now you can use the offset parameter to position it right where you want it to be, for example, you could place it bottom right either by using:

position: 'right'
offset: {bottom: '0px'}

Which would place it at the bottom right, and make it slide horizontally

Or:

position: 'bottom'
offset: {right: '0px'}

Which would place it at the bottom right, and make it slide vertically.

You can also combine bottom and right offset for example, to fine tune the position, and, maybe, make the tab appear outside your container.

Feel free to try it out!

24Aug/107

Why I don’t localize my jQuery plugins

That's a question (I know, the title is actually the answer to that question) I've asked to myself yesterday. I mean, why do other people deliver jQuery plugins in a full-featured package, including localizations, and I don't? Take jQueryUI and the datepicker date formats for example.

At the beginning, I chose to deliver only the jQuery plugin file, and from now I will prefer to deliver a little package containing a full example (HTML + JS + CSS + PHP - if needed -). But I don't plan to deliver localizations, more than ever.

Why?

First, I don't pretend to know other languages than French well enough. That's already difficult to find the right words in your own language when it comes to describe really shortly, often in only one or two words. I prefer to let you do this job, you will probably be better than me. :-) I release my plugins in English by default (and not French) only to make sure most people will be able to understand.

Second, I have always found that already localized plugins were difficult to blend in an existent architecture. Mostly, localized plugins provide simple javascript files containing variables corresponding to the different strings, in each language. What if you want to get the data from your server? What if you want a more dynamic way to do that? And even when you're in a simple-javascript-file flavor (which I personally like), you've got work to do by yourself. Maybe you want to get all your localized strings in the same place, or maybe you would have organized that another way. OK, all that is not that difficult, but it's always a little pain anyway.

That's why I only set the basics for internationalization. All the user-displayed strings in my plugins are customizable, so you can simply pass the localized strings in parameters. The way you get these localized strings is your business, even if I do recommend a few ones.