Yahoo! has just released a new Firebug plug-in called ySlow. I just finished installing it and playing around with it for a few minutes and it definitely looks like it could be one of those must have web developer tools. It provides the following:

• Performance report card
• HTTP/HTML summary
• List of components in the page
• Tools including JSLint

The Performance Report card is pretty slick. It provides lots of tips on improving performance—such as ways to minimize HTTP requests, removing duplicate tags, adding expiration headers, etc.

A couple of cool tidbits on the jQuery front.

Remy Sharp has written a nice, clear, concise entry on demystifying jQuery's this object. He does a really good job explaining the differences in what this means depending on the context of what you're doing. This, no pun intended, is one of the things that can be a little confusing when you're new to jQuery since the this keyword can either be a pointer to the current DOM element or a jQuery object—depending on the context of your code. Remy's write up should help to clear this up for any new jQuery users.

Ralf S. Engelschall has a released jQuery Plug-in for cross-site AJAX. His plug-in allows you to communicate to a 3rd party domain in a similar manor to the $.getScript() call. The new function he introduced is called $.getScriptXS(). He's even added support for callbacks, so you'll know when the script has loaded. Very nice!

I recently upgraded a few of my installation of TortoiseSVN to the latest revision. Every since doing this, I've been unable to use Subclipse v1.0.3 (in Eclipse v3.1) to change repositories that have been touched with TortoiseSVN. This is because the newest version of TortoiseSVN using the v1.4 of the client libraries and Subclipse v1.0.3 is based on the old v1.3 client files.

Since one of my development boxes only has Eclipse w/Subclipse, it's been a pain to deal w/this compatibility issue. So, this morning I set out to find a solution to this issue.

Fortunately, I was able to find a post by Mark Phippard that addresses solving this issue (while for Subclipse v1.1.6 anyway.) I did run into an issue that apparently doesn't affect the newer version of Subclipse, but since I'm still using Eclipse v3.1 at the moment, I'm stuck using Subclipse v1.0.3.

In response to Microsoft releasing Internet Explorer 7, Mozilla has released Firefox v2.0. You can download the English version of FF2 for Windows at http://www.mozilla.com/products/download.html?product=firefox-2.0&os=win&lang=en-US.

I haven't installed this yet. I may actually do a completely clean/fresh install of FF2 (just because I haven't done a clean install in a long time of Firefox) and then just migrate my settings over.

For those of you using Fiddler HTTP Debugger (which is a great tool I've blogged about many times in the past,) there appears to be an issue when using IP addresses. This is especially noticable when using private subnet IP addresses (such as 192.168.1.*.)

The problem I was seeing was that requests to my developer server came to a crawl when using Fiddler. Speed to external domains was working fine. If I turned off capturing, speed resumed. I finally was able to figure out that by setting up a DNS entry, speed would resume.

Since this was slowing me down, I sent Eric Law, the developer of Fiddler, an e-mail message reporting the problem. He was very quick in researching the problem.

GoogieSpell is a cool little Gmail-like spell checker for use in your own web-based applications. They include several server-side scripts that you can use to connect to Google's Spell Checking Web Service. Unfortunately, ColdFusion isn't one scripts they provide.

However, Robert (over at RedBalloon Labs) has written an article on how to use the GoogieSpell API within your ColdFusion applications.

I've run into this problem from time-to-time. I think the main time I run into the problem is when uploading files to a server, where the form submit is triggered by JavaScript—although I haven't dug around enough to confirm if this is the case or not. Anyway, here's a way to increase the default timeout.

The dom.max_script_run_time is an integer that is the number of seconds to wait before prompting that a script is taking too long to respond. I found this information over at Itchy Hands.

Ever since I upgraded to Firefox 1.5, I’ve been getting some unresponsive script warnings on sites that employ heavy Javascript like Gmail or Bloglines. Curious about it, I dug around and managed to find out how to fix the problem.

To fix it, you’ll need to access the hidden configuration page in Firefox. Just type about:config in the address bar and you’ll get a page full of hidden configurations which you can tweak till your heart’s delight.

In the 'Filter' box, type dom.max_script_run_time. This will narrow the options till only the dom.max_script_run_time option remains. Right-click it and choose Modify. A box pops up. Change the number to something bigger like 20. This is the maximum time a script can run before Firefox considers it 'unresponsive'.

If you can’t find the string in the about:config page, create it by right-clicking anywhere and then choose New—> Integer and enter dom.max_script_run_time. When prompted for the value, use 20.

So far I’ve not had anymore unresponsive script warnings, so I guessed that fixed that problem! However some extensions may also cause similar problems. Hope this helps.

- Itchy Hands

At work, I had a client who was having problems with our website crashing Firefox. Suspecting a problem with an extension, the first step I had the person do was to disable all their plug-ins—thinking that would be enough to determine if an extension was causing the problem. While, I learned the hard way that just disabling an extension won't necessary make Firefox behave like the extension isn't installed.

After some basic troubleshooting, I discovered the browser would crash any time a window.close() method was called (self.close() caused the same behavior.) Once again, I really suspected this had to be an extension issue. This time I had the client start Firefox in "safe mode". Sure enough, everything began working as expected.

I knew the client was using an extension called "Tabbrowser Extensions 2.1.2006031301". My original gut instinct was it was this extension that was causing the crashing. However, like I stated, I assumed just disabling the extension would get rid of any side effects it might be introducing. This was wrong. I think the reason why disabling this extension didn't avoid the problem, was because the extension loads a preference file that overwrites normal Firefox configuration options and that simply disabling the extension doesn't prevent the preference file from being loaded. After uninstalling the extension, their browser started working correctly.

From time to time I've seen people complain about how boring and unflexible HTML forms are in terms of looks. Some of the designers I've talked to really hate the default button elements, especially when it comes to the radio and checkbox elements.

I was doing some surfing last week and came across some example code on Eric Dolecki's blog which he labelled CSS Radio Buttons. Essentially he was using some JavaScript to hide the default input elements and replace them with images. The code was pretty neat, but a little cumbersome and involves having to add a lot of hooks. So, I spent a couple of hours over the weekend and through together a very rudimentary "Skins" plug-in for qForms.

I've only tested the code in Firefox and IE at the moment, but it seems to work pretty well. In order to see the full effect, your browser will have to support the insertBefore() method. Essentially what the code does is parses through the field elements in a form looking for the type of element you're skinning (currently only checkboxes and radio elements are support.) It'll then hide the element by setting the display property to "none". It'll then insert an image into the DOM right before the input element which has event's attached to the onclick event which will replicate the input element's functionality.

The buzzword "AJAX" is becoming all the rage these days. While the concept surely isn't new, the method of delivery has changed. A comment by Oguz Demirkapi over on Mark Kruger's "Client Side and Server Side Validation - a case for both" blog post got me thinking about AJAX and qForms. Oguz said:

and we use also Ajax for server side checks. As an example: while registering for our website our Ajax code check whether entered e-mail address has already been in database or not. And than show error msg directly as client side action.

It is a really great option to check availibility etc.

With all the changes I've made to qForms, I figured it would be pretty easy to throw together a little example form that used AJAX techniques to validate a field against live server data. Instead of using a validation method, were instead going to check the value onblur (so that we can then query the server while the user is interacting with the rest of the form) and then we'll display an error is the user has selected a user name that's already being used.

Last night I was thinking about the changes I had made to the createDependencyTo() method and started thinking that there might be times when you'd want to do something similiar, but instead of having one field affect another in some manor you'd define a rule for a field if it meets a given condition.

My basic thought would be to add a new method you could call. I've been tossing around the idea of setActionRule(), setConditionAction() or setConditionalRule(). Something along those lines. The idea would be that if the value of the field this method was attached to equal a condition supplied, a function would be triggered.

When I was looking through my demo templates, I came across an example that showed some features in qForms v2.0 that I had forgotten I implemented, but it's something that's very cool and provides a lot of flexibility. What is this code you ask? Well, it deals with the createDepedencyTo() method.

For those of you who aren't familiar with this method, in a nutshell the createDependencyTo() method is used to build rule logic into your forms. For example, maybe you only want to require a user to enter their e-mail address if they've actually selected to have something e-mailed to them. You could do that like this:

I was doing some surfing today and came across a cool effect on the w3compliler Contact Us form. When you're focused on a form field, the field's label style will change to give you a better visual representation of where you're at on the form. I thought to myself, that's pretty cool--I bet I can do that with just a coupe of lines of code in qForms v2.

In the w3compiler Contact Form, they're using tables to layout the form, but I wanted to do something using strictly CSS and HTML. So I decided to use the actual <label> tag as the field label—this allows you to click on the label to set the focus to the form field. Check out my version:

qForms v2 Demo - Field Focus DHTML

Ok, here's some live demos of the qForms. If you attempt to download the source and use it in a project, you're using it at your own risk—your on your own.

http://www.pengoworks.com/qforms/v2/demo/

I'll try to keep this fairly up-to-date w/what's going on with the source code, especially if more demos are put together.

I sent this letter to the qForms Mailing List earlier and figured I'd better post it here. Leave me a comment if you're interested in helping with development.

I know many of you have been waiting a long time for news on v2. Believe it or not, it does actually exist. The reason why it's been in sort of permanent hiatus was because I really wasn't doing any work that corresponded w/furthering the development.

qForms v2 is like 95% complete, and has been, for a long time. There have been a few key features I just have never had the time to sit down and really figure out. The key features I wanted to introduce for rev 2 that aren't done to my satisfaction yet are:

• Applying validation rules to a qGroups (a qGroup is a group of fields that work as a single field. Picture splitting a phone number into separate fields for area code, prefix, suffix, etc and being able to use getValue()/setValue() to retrieve the values of all the fields as one string.)
• Event queuing. One of the things I want to do is get it to the point where you can safely write add-on hooks w/out fear of them interfering w/other add-ons you must load. This still needs improvement.
• Masking—still needs some improvements. I've re-written the code from scratch several times.

There are other things that can probably be done to improve things and I think the project really needs some new energy as I think that will help re-spark my energy for the project.

So, where am I going w/all this? Well, last night I submitted a new project request at Tigris.org. I'm hoping that those guys will approve the project soon (or I'll be looking for a new SVN home.)

What's this mean? Well, I'm planning on opening up the SVN repository for open development. Instead of opening the floodgates and letting everyone have access to the SVN repository, I'd prefer to have some volunteers from some of you who are willing to help out on the project.

So, I'm looking for experience JS programmers who have some experience w/Subversion (that's the source control I'm using) and who would like to help out on the qForms project.

As soon as the guys at Tigris approve the project, the URL for qForms SVN will be:

http://qforms.tigris.org/

For those of you not interested in following the actual day-to-day things, keep going to www.pengoworks.com/qforms for updates. However, if you're always interested in playing around w/the latest and possibly unstable builds, that's the place to go.

I'm also going to be posting the language files there (as qForms v2 supports internationalization.)

For those of who never saw it or what to see it again, you can view a preview of qForms v2 at:

http://www.pengoworks.com/qforms/preview/

Here's a brief list of what I have added:

• Internationalization
• Auto tabbing (via the setMaxLenght() method)
• Remove validation rules on-the-fly
• Keystroke dynamic masking
• Disable/Enable validation rules per form
• Much more customizable. (See the preview for how you can replace the default alert() handlers and drive everything via DHTML.)

-Dan