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]
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.
Argh…. yet again, this crappy product has another bug that developers must work around!
There’s a great quote I found while researching this…
Microsoft ‘chimes in’:
Tools to help:
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!).
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 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.
- 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.
- Modify the Apache httpd.conf file to enable (uncomment or add the following lines).
AddHandler cgi-script .cgi
AddHandler cgi-script .pl
- Restart Windows to ensure that the new configuration is available to the operating system.
- Test your install…a) Create a new file on the server named /cgi-bin/hello.pl with the following content:
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.