TEXTAREA maxlength – or lack of!

I’m not sure why this was previously overlooked in HTML4/XHTML1, but it’s been a real pain for developers for years. The ‘rows’ and ‘cols’ attributes are useless (like ‘size’ is in the INPUT tag) as they are based on display size of fixed-width fonts like Courier and not the actual input limitations. INPUT has always supported a ‘maxlength’ attribute for this purpose.

Good news, this is part of WebForms2 and HTML5 (proposal) plans to add it!

A decent fix that I currently use… optimally you would use a common ‘maxsize’ function.

[textarea name=”junit” id=”junit” onkeyup=”maxsize(this,100);”][/textarea]
[script type=”text/javascript”]
function maxsize(obj,mx){
obj.value=obj.value.substring(0,mx); }


You should ALWAYS perform server-side validation of the length too, otherwise you leave the door open for someone to hack your form and submit longer data.



MSIE6 javascript memory leaks

Argh…. yet again, this crappy product has another bug that developers must work around!

It seems that Microsoft doesn’t release memory to javascript objects from memory when created on a page… even when the page is unloaded.

Let’s think about this one for a second, why would you want to keep a javascript variable or DOM reference in memory after the user has navigated away from that page? This violates the stateless paradigm that web applications generally work with, besides… how would a developer be able to get that information (memory) back on the next page anyways? Perhaps, it was some genious that tried to keep state in javascript when the ‘BACK’ button was pressed… we’ll probably never know.

There’s a great quote I found while researching this…

“IE has an issue where it leaks memory when a circular reference is created between a COM object and a javascript object. In IE, the DOM is implemented via COM ….. This memory is not reclaimed until the browser closes. The simplest solution is to pretend there is no garbage collector for objects and make sure you always clean-up after yourself.”


Microsoft ‘chimes in’:

Tools to help:


Automated Java code review tools

I recently found out about ‘static analysis’ of Java code. I’ve found two of these tools that are both free and easy to use. Both provide review of java bytecode and look for common development errors and inefficiencies…
FindBugs is based on the concept of bug patterns. A bug pattern is a code idiom that is often an error. Bug patterns arise for a variety of reasons:

  • Difficult language features
  • Misunderstood API methods
  • Misunderstood invariants when code is modified during maintenance
  • Garden variety mistakes: typos, use of the wrong boolean operator

PMD scans Java source code and looks for potential problems like:

  • Possible bugs – empty try/catch/finally/switch statements
  • Dead code – unused local variables, parameters and private methods
  • Suboptimal code – wasteful String/StringBuffer usage
  • Overcomplicated expressions – unnecessary if statements, for loops that could be while loops
  • Duplicate code – copied/pasted code means copied/pasted bugs

Both integrate easily within Eclipse based (and other IDE’s) is typically done with the use of a simple plugin.

FindBugs can also run as a Java WebStart (JNLP) application, however a different UI is shown for JRE 1.4 vs. 1.5 and above (look out!).
More information:

While no tool can identify all problems, these will help you find some troublesome problems and give you areas to take a deeper look at.

Happy reviewing and fixing.

Installing Perl CGI on Apache (for Windows)

Installing Perl on a Win32 installation of Apache is trivial. Just a few short years ago (roughly the year 2000) most commercial website still ran large amounts of Perl code. Several open-source projects like BugZilla still rely on this powerful scripting language.

Here’s a few simple steps and advice to consider when the need comes to add this feature to your installation.

  1. Download Perl for Win32 – ActiveState Perl is the standard distribution to use, and installation is a snap.URL = http://www.activestate.com/Products/ActivePerl/a) Get the MSI file version as it’s executable (the AS version is a ZIP file for manual installs)

    b) The default path it chooses is “C:\Perl”, I advise that you use “c:\usr” instead as it makes it easier to port programs to and from UNIX/LINUX.

    c) The MSI installer takes care of the PATH file settings, so you should have no other work for installation.

  2. Modify the Apache httpd.conf file to enable (uncomment or add the following lines).

    AddHandler cgi-script .cgi
    AddHandler cgi-script .pl

  3. Restart Windows to ensure that the new configuration is available to the operating system.
  4. Test your install…a) Create a new file on the server named /cgi-bin/hello.pl with the following content:

    print “Content-type:text/html\n\n”;
    print “hello world”;

    b) Start (or restart) the Apache service.

    c) Access the file in the browser, example:

    URL = http://localhost/cgi-bin/hello.pl

    d) If everything works, you should see the words “hello world”, otherwise, if you see the source code or ‘500 Server Error’ then the config has a problem.

Happy Scripting.