Disable Form Field, Preserving Submit

The “disabled” attribute on an HTML form element prevents the field from being edited. Unfortunately, it also prevents the field from being submitted in the form. If you do need to submit the field even though it’s disabled, use the following instead of the disabled attribute:

this.event.addListener( field, “click”, function(e)

{

var targ;

if (e.target) targ = e.target;

else if (e.srcElement) targ = e.srcElement;

if (targ.nodeType == 3) // defeat Safari bug

targ = targ.parentNode;

targ.blur();

});

YAHOO.util.Event.addListener( field, “click”, function(e)

{

var targ;

if (e.target) targ = e.target;

else if (e.srcElement) targ = e.srcElement;

if (targ.nodeType == 3) // defeat Safari bug

targ = targ.parentNode;

targ.blur();

});

This will blur (deselect) the field as soon as you select it. Combine it with some gray styling and you’ve got a great form disabler.

Top Reasons Your YUI Widget Looks Messed Up

1. You created the widget but didn’t call its render() method. When you create it, that seems to update some styles and DOM elements, but not all. Calling render() updates the rest.
2. You tried to apply the widget to multiple elements, but, since they have the same ID, it was applied to the same element multiple times. This is like the Ghostbusters crossing the streams, and is very bad.

JavaScript Documentation Recommendations

For the project I’m currently working on, here are some best practices I’m using for JavaScript documentation:

• Use YUI Doc syntax. Even if I never actually run YUI Doc, it’s a standardized comment format.
• At the top of every JS source file, put a multi-line comment, with the first line starting with the source file name. I combine my JS files in the build process, so this allows me to easily find out which source file a particular line of code is from. I even add these headers to JS library files I use.
• In that file header comment, add an @global directive that lists all the global variables the file creates. Ideally, each of your files would correspond to an @module, and you wouldn’t create any global variables other than classes in that module; and any instances you create would be inside anonymous closures. But some JS libraries you use may create global variables (DWR, for example), and it’s helpful to document the variables they create.

YUI Logger Bookmarklet

So you’re using YUI Logger in your webapp, and loving it. One problem: how do you hide the console for production, but show it in development? You can have separate build targets, but what if you want to deploy the same package in all your environments?

One option is to use this bookmarklet to load YUI Logger. In other words, just load your page, then run the bookmarklet to load the logger.

One of the upsides of that bookmarklet is that it uses YUI Loader to load the logger code dynamically, so that you don’t have to include the logger code in your production side. The bookmarklet doesn’t work if you don’t have YUI Loader included on your page. For me, though, this was a problem. I don’t use YUI Loader – instead, I combine all my JavaScript library code into a single JS file that’s downloaded once, so that can be cached. And when I looked at the YUI Loader code, it’s actually larger than the YUI Logger code!

So, as an alternative, here’s a bookmarklet that will start a YUI Logger console, assuming you already have the logger code loaded into your page. Bookmark it, or drag it to your toolbar or bookmarks folder.

YUI Log

Note: as far as I can tell, your log statements are recorded even before the console is displayed, so if you have code that executes on page load, its log statements will still appear in the console when you use the bookmarklet after page load.

Sample App 0.1.1 Released

I’ve just uploaded a minor patch to Sample App. This fixes some errors in the production build targets, and adds more thorough JavaDoc and YUI Doc.

sample-app-0.1.1.zip – 20.6 MB

You can also find out more about Sample App.

Sample App 0.1 Released

I’ve just posted a Java webapp called “Sample App” (until I can think of a better name for it). The goal for this webapp is to be a project template using industry-standard libraries and best-practices for full-stack Java application development, from a high-performance rich client tier, back to the database. There’s nothing particularly revolutionary about it, but it’s hard to find this particular combination of features – especially a combined rich frontend and backend. It’s released under a BSD license.

sample-app-0.1.zip

Check it out, take what’s helpful to you, and improve on the rest!

Features

• Client
  • Logging (YUI Logger)
  • Combination of assets to save on HTTP requests
  • CSS sprites automatically generated (SmartSprites)
  • Minification (YUI Compressor)
  • Ajax requests (YUI Connection)
  • Strict presentation logic boundary (JSTL)
  • Copy in properties files
  • Object-oriented JavaScript
  • Event binding performed by JavaScript, not in markup
• Server
  • Separation of business logic and webapp into distinct projects
  • Dependency injection (Spring)
  • Unit testing (JUnit)
  • MVC (Struts configured via Spring)
  • ORM (Hibernate)
  • Logging (Log4J)
  • Separate Business Logic and DAO tiers
• Build
  • Separate build targets for dev and prod environments, changing config files, adding additional JS, and enabling/disabling logging and minification
  • Run on local box from a bare checkout using a build target, without any additional configuration or native code (Jetty, HSQLDB)

Requirements:

• JDK 1.5 or above
• Ant 1.6.5 or above

Getting Started:

Download the zip file above, expand it, go to sample-webapp/build, and run ant. This will run the default target run-dev. The app will then be accessible on your local computer at http://localhost:8080/sample-webapp/

YUI Calendar Changes Dates

My Ajax app has a persistent date it keeps track of, to compare other dates against. But I ran into a problem where the date was somehow being changed – from 12am on a certain day to 12pm. I looked through my code, and I wasn’t even changing it anywhere.

Finally, I noticed I was passing the date into a YUI Calendar object, to specify what was the minimum allowable selectable date. JavaScript Date objects are mutable, so I realized it was possible YUI was changing the hour value on the date. Sure enough, when I changed the code to pass YUI a copy of the Date instead, the date’s hour was no longer changed.

I’m still not entirely sure why YUI would need to change the Date, or if it’s even good design for it to do so instead of creating a copy of the Date object. Nonetheless, lesson learned: if you want to make sure an object you’re passing somewhere is unchanged, make a copy before you pass it. This smacks of a general OO principle, but for some reason I haven’t run across this problem in the Java world before.

IE6 :hover Support

IE6 does not support :hover pseudo-classes on non-anchor elements. Ugh.

There are a few fixes out there. This one uses prototype. I was able to translate it to use YUI Event and Dom pretty easily. Wish I had an open-source agreement with my employer so I could show it here.

YUI Editor Does Not Hide Properly

I tried to use a YUI Rich Text Editor inside a YUI Panel that starts out hidden. However, some of the time, the place that the YUI Editor occupies was covered with a white square, even when the panel was hidden.

This example by Dav Glass provides the solution. IE6 does not properly handle visibility:hidden for iframes. The solution is to position the iframe offscreen when it’s hidden, and restore it when it’s shown again.

Multiple YUI Modal Panels

Creating a page with several different modal YUI panels (popup “windows”). Some of the modals were showing up behind the overlay that shades and disables the rest of the page.

When I looked at the DOM, it turns out that I didn’t properly close some tags, so some of the modals were actually inside the other modals. Any time a YUI panel isn’t a child of the body element, that can cause problems with modality. Fixing the closing tags fixed it.