Getting to grips with the jQuery Validation plugin

Introduction

Recently I was assigned the task of adding some validation to a new HTML form. The form itself was nothing out of the ordinary. A standard user registration page like you see everywhere on the web today. The only requirement was that the validation be performed client side. Again, this is what you see on most modern web applications in 2012.

I’m a big believer in reusing existing components, but the trick is to pick the components that are viable to be maintained in the future. Since jQuery was already in use on the project then a jQuery plugin seemed appropriate. jQuery plugins are in abundance on the Internet today, but if I’m going to use something I want it to be maintained and compatible with future versions of jQuery. I knew of the jQuery Validation plugin since I had used it in a previous project. However, I was a little reluctant to jump in with both feet first since I found it a little awkward to work with the last time around. Needless to say, this time it did the job for me, but when trying to get familiar with its usage, good documentation was hard to find.

Now, that’s doesn’t mean that good documentation doesn’t exist, it’s just that a lot of the examples you find on the Internet are either much too simple (and use the simple validation syntax), or they are cluttered with a lot of other unnecessary JavaScript code that overcomplicates the essence of illustrating the validation in action. A good starting point for documentation is the official page from jQuery, but beware, there is so much more to this useful plugin than their examples show you. So let me share my experiences with you here and let you be the judge.

The source code

First things first. All the examples I will be showing you can be downloaded from github. Just head on over to GitHub and download them. There are only five of them and they are very easy to read. You can follow along from the first example and start building a working HTML form.

Create validation for a simple form

When you create an HTML web form you sometimes are a little lenient with the standard attributes used on the input tags – at least I am. It took me a while to figure it out, but the validation plugin won’t work unless the input form tags have a name attribute defined. Take a look at the example below:

<!DOCTYPE html>
<html>
    <head>
        <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js" type="text/javascript"></script>
        <script src="http://ajax.aspnetcdn.com/ajax/jquery.validate/1.9/jquery.validate.min.js" type="text/javascript"></script>
        <script src="js/example1.js" type="text/javascript"></script>
    </head>
    <body>
        <form id="validation" action="">
            <fieldset>
                <label id="name-label" for="name">Name:</label>
                <input id="name" name="name" type="text" />
            </fieldset>
            <input id="submit" name="submit" type="submit" value="Validate" />
        </form>
    </body>
</html>
$(document).ready(function () {
    $("form").validate({
        debug: true,
        rules: {
            name: {
                required: true
            }
        }
    });
});

Output of example 1

This is as simple as it gets, but you will see simpler examples than this that make use of the jQuery Validation plugin, most of which use the “easy” configuration syntax adding attributes to the form input fields directly. In my opinion, this approach does not scale and clutters the markup. I prefer a clearer, predictable JavaScript syntax and I don’t mind writing an extra few lines of code to do so. The Validation configuration syntax I’m showing you here is what you should strive for and it will also let your form validation scale. In my experience forms always need to scale so do it right from the start.

This form is easy. It only has one input field. Notice the rules keyword in the validation configuration. Using the input field’s name attribute you define the validation rules for each field. When the user hits the submit button the form will be validated before a POST is attempted. The debug setting is good to have turned on. It will write any errors or warnings to the browsers JavaScript console. It was this helpful setting that made me aware that I was missing the name attribute on my input form fields.

Let’s move on.

Adding more fields

The second example (below) adds a few more fields. You will also notice that I have started to use validation methods here. For instance, now you must type a name of at least 7 characters. The address can be of any length, but it is still required. The zip code must consist of at least 5 digits, and only digits. You can read more about the Validation methods here.

Notice the code for the messages keyword and compare it with rules keyword. You will no doubt see that each validation method has its own custom validation message. I thought that was a pretty nice touch and makes user feedback easy. You don’t have to add your own custom validation messages, but if you don’t then you will get the jQuery Validation plugins own error messages.

Go ahead and run the example in your browser. Use the TAB key to move from field to field. Notice the validation at work when you move from field to field.

<form id="validation" action="">
    <fieldset>
        <div>
            <label id="name-label" for="name">Name:</label>
            <input id="name" name="name" type="text" />
        </div>
        <div>
            <label id="address-label" for="address">Address:</label>
            <input id="address" name="address" type="text" />
        </div>
        <div>
            <label id="zipcode-label" for="zipcode">Zip code:</label>
            <input id="zipcode" name="zipcode" type="text" />
        </div>                
    </fieldset>            
    <input id="submit" name="submit" type="submit" value="Validate" />
</form>
$(document).ready(function () {
    $("form").validate({
        debug: true,
        rules: {
            name: {
                required: true,
                minlength: 7
            },
            address: {
                required: true
            },
            zipcode: {
                required: true,
                digits: true,
                minlength: 5
            }
        },
        messages: {
            name: {
                required: "Required name",
                minlength: "Your name is too short. Must be at least {0} characters."
            },
            address: {
                required: "Required address"
            },
            zipcode: {
                required: "Required zipcode",
                digits: "Only digits accepted",
                minlength: "A minimum of {0} digits are required."
            }
        }
    });
});

Output of example 2

If your input does not validate the error message is displayed at once. You don’t need to submit the form. This a configuration setting that can be easily changed, but I am using the defaults.

The validation error message

You may have noticed that the error message that pops up for the validation is not something that is present in the markup itself. The jQuery Validation plugin is inserting it in to the markup at runtime. In most cases you will want to do something with the presentation of the validation error messages. There are a number of things you can do, but by default the validation plugin encloses the error message in an html label tag with a class named error. It also adds an error class to the input field that failed to validate and a valid class to inputs that are considered valid.
The easy thing to do is to simply create a class for the input and add it to the CSS style sheet. If you run the next example you will see a simple way to style the default error messages. The code is identical to previous example apart from the addition and inclusion of the CSS file. I have also played with the presentation of the error message text and added a valid input style. There are numerous possibilities here including using something other than the html label tag. Check out the errorElement setting in the plugin configuration documentation.

input.valid {
    border: 2px solid green;
}

input.error {
    border: 2px solid red;
}

label.error {
    color: red;
    font-weight: bold;
}

Output of example 3

Giving your use options, but choose at least one

Check boxes are the preferred choice for entering multiple choice input. Validation can be somewhat tricky in this scenario. You can’t simple set a check box validation rule to required since the input is never required. However, sometimes you have to ensure that the user has picked at least one. When reading the documentation to see how this could be done I came across something called grouping, however, I couldn’t get it to work for my scenario. However, I did manage to support this feature by adding a custom validation method and using a hidden form field. The hidden field acts as a place holder to call the custom validation method. It doesn’t really do anything, but the validation uses the jQuery method connected to it to check if a check box is ticked.

Take a look at the next example. Notice the custom validation method at the top, requireOne. It’s purpose is simply to check if one of the check boxes is ticked and then return true or false. However, there is a slight flaw in the plan. Hidden fields are not by default validated by the validation plugin. The call to setDefaults() makes every form element a candidate for validation including hidden fields.

Notice the call to $(“#hiddenOptionValidator”).valid() at the end of the script. I had to add this code to force the plugin to validate the hidden field again once a check box is ticked or unticked. Without this the validation error message for the check boxes will not be cleared until the submit button is pressed which will most likely confuse a user.

<form id="validation" action="">
    <fieldset>
        <div>
            <label id="name-label" for="name">Name:</label>
            <input id="name" name="name" type="text" />
        </div>
        <div>
            <label id="address-label" for="address">Address:</label>
            <input id="address" name="address" type="text" />
        </div>
        <div>
            <label id="zipcode-label" for="zipcode">Zip code:</label>
            <input id="zipcode" name="zipcode" type="text" />
        </div>             
        <div>
            <div>
                <input id="option1" name="option1" type="checkbox" />
                <label for="option1">Option 1</label>
            </div>
            <div>
                <input id="option2" name="option2" type="checkbox" />
                <label for="option2">Option 2</label>
            </div>
            <div>                    
                <input id="option3" name="option3" type="checkbox" />
                <label for="option3">Option 3</label>                            
            </div>
            <div>
                <input id="hiddenOptionValidator" name="hiddenOptionValidator" type="hidden" />
            </div>                    
        </div>
    </fieldset>            
    <input id="submit" name="submit" type="submit" value="Validate" />
</form>
$.validator.addMethod("requireOne",
                        function (value, element) {
                            return $('input[type="checkbox"]:checked').size() > 0;
                        },
                        "Missing required status - Must choose one");

$.validator.setDefaults({ ignore: [] });

$(document).ready(function () {
    $("form").validate({
        debug: true,
        rules: {
            name: {
                required: true,
                minlength: 7
            },
            address: {
                required: true
            },
            zipcode: {
                required: true,
                digits: true,
                minlength: 5
            },
            hiddenOptionValidator: {
                requireOne: true
            }
        },
        messages: {
            name: {
                required: "Required name",
                minlength: "Your name is too short. Must be at least {0} characters."
            },
            address: {
                required: "Required address"
            },
            zipcode: {
                required: "Required zipcode",
                digits: "Only digits accepted",
                minlength: "A minimum of {0} digits are required."
            },
            hiddenOptionValidator: {
                requireOne: "Please tick one checkbox"
            }
        }
    });

    $("input[type='checkbox']").click(function() {
        $("#hiddenOptionValidator").valid();
    });
});

Output of example 4

Validating input based on remote data

Validating input fields is pretty simple, but can quickly elevate up to a something more advanced if you want to do an online lookup for data in a database.

Let’s say you want to register a new user in your system and the unique key is the user’s email address. In most scenarios two users won’t have the same e-mail address since this is unique, but if the same user returns to your registration form and wants to re-register then you have to avoid a new registration and take action before submitting the form. Using the validation email method will handle a user typing a valid e-mail address. Once you are past that hurdle you want to use the remote keyword to look up a backend service to connect to the validation. The documentation is severely lacking here, but luckily it isn’t as hard as it sounds. You do need a backend service to get this working. The thing to remember is that the syntax for the remote keyword configuration is identical to jQuery’s AJAX requests. If you have used AJAX in jQuery before, this should be pretty similar. To set up a backend service is beyond the scope of this article, but take a look at the code example and I’m sure you’ll see what you have to do.

<div>
    <label id="email-label" for="email">E-mail:</label>
    <input id="email" name="email" type="text" />
</div>  
            zipcode: {
                required: true,
                digits: true,
                minlength: 5
            },
            email: {
                required: true,
                email: true,
                remote: {
                    type: "GET",
                    url: "/your-service-url/",
                    cache: false,
                    data: {
                        mail: function () {
                            return $("#mail").val();
                        }
                    },
                    dataType: "json",
                    dataFilter: function (data) {
                        if (data) {
                            var json = $.parseJSON(data);

                            if (json) {
                                return JSON.stringify(json.available);
                            }
                        }

                        return false;
                    }
                }
            },
            hiddenOptionValidator: {
                requireOne: true
            }
        },
        messages: {
            name: {

Output of example 5

Closing

So there you have it! Some simple examples of jQuery Validation plugin usage based on code from the real world. If you are interested in seeing the form on which this posting is based then take a look at this link.
Your feedback, good or bad, is appreciated as always so don’t be afraid to leave a comment. Thanks for reading.

Using Fiddler as a simple http development server

Fiddler’s AutoResponder

Lately I’ve been playing around with Fiddler (version 2.3.4.4). Fiddler it is a free packet analyzer for web debugging HTTP and HTTPS traffic. It acts as a proxy between your web browser and a web server so you direct your web browser to it using a plugin (for Firefox) and it enables you to analyze and tamper with the HTTP requests and responses between the server and client. Very cool and very useful.

Screenshot of Fiddler user interface

Although Fiddler is packed with lots of useful functionality for analyzing and tampering with HTTP traffic I also found a new use for it when working with jQuery and JSON.

Just recently I was looking in to the jQuery UI Autocomplete plugin and wanted to play around with the functionality that uses JSON returned from the server. To simplify, my idea was to test the Javascript client code without writing any server-side code. Of course I could have simulated something similar by creating JSON in the Javascript code, but that’s not what I wanted here since I it was important to get familiar with the code making the JSON request over the wire. The client code that I ended up creating with can easily be deployed to a proper web server without modification.

Fiddler’s AutoResponder functionality

Fiddler includes something called AutoResponder. As the name gives away, you use it to automatically send a response to a calling browser client. The idea is to get Fiddler to intervene and return something useful when the browser makes a request for a particular URI. In my case I was aiming at making Fiddler return static JSON to the browser when making a call to http://server.anywhere.com/json. I created the contents of a HTTP response that I wanted to be returned to the browser in a file and stored it to disk. Then I redirected the AutoResponder to return this file when the browser request was made. I made no modifications to my hosts file.

Screenshot of the configured AutoResponder in Fiddler

Very simple really. As you can see from the screenshot above. I have configured two URIs. One is for the index.html file and the other for the JSON “service”. When one of the URIs is hit by the browser the corresponding file on the file system will be returned. The AutoResponder also lets me set latency so I simulated a 3000 ms sleep for the service before responding.

The tricky part was actually making a valid HTTP file for the JSON service. In my case it looked as shown below and saved as UTF-8. For this purpose I found Notepad++ to be very useful. When selecting the actual HTTP content text in the file it tells you exactly how many bytes are needed as value for the content length header. In my case it was 87 bytes.

A screenshot of calculating the number of bytes in the html response with Notepad++

Now, when opening the browser and making a call to http://server.anywhere.com/json the AutoResponder will step in and return the JSON to the browser. The code I used for invoking the call to return the JSON is shown below. Of course this code ignores what is typed in the input field and results the same JSON regardless, but for my purpose that’s okay.

<html>
    <head>
        <title>jQuery Autocompletion with JSON call</title>
        
        <link rel="stylesheet" 
              type="text/css" 
              href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.5/themes/ui-lightness/jquery-ui.css" />

        <script type="text/javascript" 
                src="http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script>
              
        <script type="text/javascript" 
                src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.5/jquery-ui.min.js"></script>
        
        <script type="text/javascript">
            $(document).ready(function() {
                $( "#tags" ).autocomplete({
                    source: function(request, response) {                                               
                        var url = "json";
                        var param = "";
     
                        $.getJSON(url, param, function(data) {
                            response(data);
                        });
                    }
                });
            });
            </script>        
    </head>

    <body>
        <div class="demo">
            <div class="ui-widget">
                <label for="tags">Tags: </label>
                <input id="tags" />
            </div>
        </div>
    </body>
</html>

Same origin policy

When requesting data using Javascript there are some security limitations that the browser enforces, one being the same origin policy. This policy restricts Javascript from accessing JSON from a different domain than the one hosting the script making the call. So if I want to request JSON from http://server.anywhere.com/json then the Javascript which makes the JSON call needs to originate from the same domain, http://server.anywhere.com/.

Again, AutoResponder to the rescue. I set up the AutoResponder to call my html page (the file which includes my Javascript) and mapped this file to a known URI from the same domain as the simulated JSON service. When the browser makes the initial request to http://server.anywhere.com/index.html, Fiddler’s AutoResponder intercepts the request and redirects a file from my local drive to the browser. The browser thinks it’s getting files from the web, but in fact Fiddler is just redirecting files from my local hard drive. When the time comes to trigger the script requesting the JSON from the simulate service at http://server.anywhere.com/json the AutoResponder steps in and returns my static JSON file. Notice the host name in the screen shot below and the jQuery autocomplete plugin in action.

Screenshot of the resultsing page in browser

Maybe a little clumsy to set up, but once done you can tweak everything in the files and no need to deploy any code or install any servers. I thought it was a nice touch that the AutoResponder can simulate latency so you can test any timeout functionality on the client side without having to add thread sleeps which usually is the case for service development.

Conclusion

I am really happy with Fiddler. I have used WireShark in the past, but for working with HTTP traffic it is a little too heavy. Fiddler has a lot of interesting features for web development and analysis work.

Encouraging signs for web development on the Microsoft ASP.NET 4.0 platform

This really seems like a good time to be working with Microsoft web technologies. Not only has ASP.NET 4.0 just shipped along with a new version of Visual Studio, but there seems to be a focus on more openness and willingness to adhere to web standards and co-operate with the community. Coming from an open-source world this is a familiar mindset to me, and although I only recently have crossed over to the Microsoft platform, the idea of community driven development still appeals to me. I just downloaded the 2010 Express versions of Microsoft Visual Web Developer and Microsoft Visual C# and my initial impressions are good.

I prefer doing my client-side scripting using jQuery and have done so successfully for a few years now. Followers of this blog will know that I recently completed my ASP.NET 3.5 certification. What I found a little annoying when studying for the exam was having to delve in to the details of the Microsoft AJAX library knowing full well that I would probably never use any of it. Yesterday I came across Stephen Walthers article regarding Microsoft’s contribution to the jQuery project. I was encouraged to read that Microsoft will be further shifting their investment to contributing to the jQuery project and moving away from Microsoft client-side Ajax. However, although I will probably never use the Microsoft AJAX library in any of my projects, I consider it a benefit that I am aware of the “old ways” of doing client browser scripting from a ASP.NET perspective. I’m sure there will be plenty of code that will need to be refactored and upgraded to jQuery in years to come :-).

An encouraging project that seems very interesting is Microsoft’s ASP.NET MVC project. The ASP.NET MVC templates are now part of the Visual Studio 2010 IDE, and from what I have been reading, this will be the preferred way forward for web development on the Microsoft platform in the future. Coming from an open source Java based web development world, this is music to my ears and something I am looking forward to learning more about in the months ahead.

With the release of ASP.NET 4.0, my understanding is that there has been a focus on getting the generated ASP.NET xhtml to adhere to web standards and therefore simplifying CSS styling. This applies to both MVC and Webform development. I think this is good news since there have been a few times in the last few months where my jaw has dropped to the floor when viewing some of the xhtml source code generated from the ASP.NET 3.5 controls – especially for the data bound controls. In today’s world of correct web semantics I’m glad this finally is on the agenda and look forward to reaping the benefits in the future.

Be careful with your jQuery selectors!

I love jQuery! On my current ASP.NET 3.5 project I have a form which contains several input fields. I wanted to disable them given a condition. I created the following jQuery code:

$(document).ready(function() {
    $("input#ASP_Generated_User_Control_Prefix_Here_uxMyNumberField").keyup(function() {
        // select a selection of inputs and links
        var elements = $(":input:not(:submit)")
                       .not($(this))
                       .add("a.fxButton");

        if ($.trim($(this).val()) != "") {
            elements.attr('disabled', true);
        } else {
            elements.removeAttr('disabled');
        }
    });
});

In short this code applies to the keyup() event of input field named uxMyNumberField (the ID is autogenerated by ASP). As we will see in a moment, it is the jQuery selector which plays the star role of this blog entry. So to explain the selector: select all input fields that are not submit buttons, but exclude the current input field. Also include links of a given CSS class (fxButton) to the selection. So if a value is entered in uxMyNumberField then the code will immediately disable every element contained in the element set, and otherwise enable them (i.e. user presses backspace).

Everything worked as expected in the browser. The UI elements were being enabled and disabled when a value was entered or removed. However, when adding a value to the uxMyNumberField and clicking on the form’s submit button, the form was not being submitted as it was previously. The ASP event handler for my submit button was never being called, but I could confirm that a server request was being generated from the browser and the ASP Page’s Load event was being triggered. Curiously, the error only applied when a value was entered in the uxMyNumberField field. The remaining form fields were being submitting correctly when uxMyNumberField was empty.

To make a long story short, what was happening was the selector was also including hidden ASP input fields in the element set – fields used for internal ASP page state and event handling.

<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />

In practice this was disabling the submit button’s event handler. When correcting the selector to only include my form elements everything worked as expected.

This nasty mistake took me some time to locate and only with the aid of Firebug – what would we do without it! I was certain the error was due to an ASP validator control change I had made earlier, which only applied to the uxMyNumberField.

This was also my first experience with the Firebug Javascript debugger. When stepping through my jQuery function, the debugger showed me which elements were part of the resulting element set, which in turn immediately led me towards correcting the selector and excluding the hidden ASP input fields.

So the moral of this experience is be careful not to include fields used by the platform when creating your jQuery selectors! 🙂

Javascript mouseover effects on table rows using jQuery

Introduction
Lately I’ve been getting into jQuery. On first sight the syntax can look a bit strange, but I get it now – for the most part, that is. On a related note, for a while now I’ve been “wondering” about how you do the mouseover effects you sometimes see on table rows. I’m talking about the effects where you move your mouse over a cell in table row and then the full row’s background colour changes to give the effect of highlighting the full row for selection. I really haven’t given it much thought, but I recently came across some code in a company application that got me thinking about it again so I decided time was right for to take a closer look.

Code
Originally, before the use of jQuery, your markup would look something like this:



   <table>
      <tbody>
         <tr>
            <td>some table cell content here</td>
         </tr>
         <tr style="cursor:pointer;">
            <td>some table cell content here</td>
         </tr>
         <tr>
            ...
            more rows and cells containing more of the same here
            ...
         </tr>
      </tbody>
   </table>


You’ll notice the obtrusive JavaScript event handling code on lines 5 to 8 and 11 to 14. This code repeats itself on every row of the table which is just annoying. The only difference between the code attached to the individual table rows is the obvious onclick event handler (here a simple alert message) which should simulate some functionality specific to a click on that unique row. As a whole this use of Javascript makes the markup somewhat more difficult to read and generally untidy. Of course it is usually the backend server code creating this kind of code in a for-loop or similar – nobody writes this stuff by hand, but that’s not the point.
So how can you use jQuery to replace this mess? The following shows a first attempt of a replacement using jQuery.



   
   
      $(function() {
         $('table tbody tr').mouseover(function() {
            $(this).addClass('selectedRow');
         }).mouseout(function() {
            $(this).removeClass('selectedRow');
         }).click(function() {
            alert($('td:first', this).text());
         });
      });
   
   
      .selectedRow {
         background-color: blue;
         cursor: pointer;
      }
   


   <table border="1">
      <thead>
         <tr>
            <th>First column</th>
            <th>Second column</th>
            <th>Third column</th>
         </tr>
      </thead>
      <tbody>
         <tr>
            <td>This</td>
            <td>That</td>
            <td>The other</td>
         </tr>
         <tr>
            <td>Second</td>
            <td>line</td>
            <td>here</td>
         </tr>
      </tbody>
   </table>


So – I guess a brief explanation is in order. You’ll of course need the jQuery JavaScript library available in the correct location as referred to in the script tag (line 3). Apart from that, all the custom JavaScript jQuery code is happening in the script tag at the top of the page (lines 4 to 14). We are first creating a jQuery selector to select all tr tags inside a tbody tag which itself must reside within a table tag (line 6). When these tag elements are found we bind the ‘mouseover’, ‘mouseout’ and ‘click’ events to the rows (lines 6,8 and 10 respectively). The mouseover and mouseout event just add or remove a CSS class named ‘selectedRow’ dynamically to or from the row which adds the effect. The CSS class itself is defined at the top of the page within the style tags just after the script. The actual mouse click functionality just returns the value of the first cell in the selected row, just as an example. This could be a unique row id or similar.
The jQuery selector makes sure the mouse click event is set to only work on tr tags that are present from within a tbody tag to avoid adding the effect to the thead header row.

So that’s all there is to it really – not too bad. It was a lot simpler than I first imagined and the jQuery code makes things nice and tidy once you get used to the chained decorator pattern syntax.

Long time, no see?

Introduction
So what gives? It’s been seven months since my last posting. Have I really been all that busy that I couldn’t find the time to create a new posting?

Well, I guess it’s partly true. I have been busy, but I’m sure I could have found the time if the motivation was there. Rest assured that my guilty conscience has been forever weighing me down for not following up my ‘promising introduction’ to the bloging world. However, I think it’s fair to say that the main reason for my absence can be best described as “self inflicted censorship” – if we can call it that. I’ve been a little uncertain of what to write that would be of interest to others, and also try to avoid pissing off the people I work with. I’ve also been a little rundown at work at times so my eagerness to share my views has not been at it’s peek. Now, a few months the wiser, I guess I’ve gained a little perspective so the picture has become a clearer.

What’s been going on?
A lot has happened during the past seven months. The department I am working for at work has grown substantially from just two people (my boss and I) to around eleven and I guess I’ve been a part of that. My new boss sets targets and does her very best to reach them. Although she is a few years my junior, I’ve learned a lot from her, and for the most part I think she is great to work with. I like her positive attitude and have found it contagious at times. I also take a personal interest in management, good management that is, so I do a little reading on the subject on the side, and have been able to share my views with her on occasion. She is keen to keep everyone in the department happy and find us work that we find interesting. It’s truly great to have a boss that cares and can relate to what I’m doing. With her coming from a Java development background herself helps tremendously and means there has been a lot more focus on Java and Open source technology than earlier. As you may have guessed, that suits me fine, and I feel I have grown a lot, both on a personal and professional level. Compared to where I was a year ago, things are looking good, although the business markets have taken a turn for the worst during the last few months, so who knows what may happen in future? Fingers crossed.

Focus change
Everyone at my present workplace seems to think I live and breath for Java, but I’ve noticed that my main interest actually lies more towards web development based on open source technology than Java development. I haven’t really been following the Java scene actively for quite some time and feel I have fallen behind on the latest API’s and frameworks. At present Java just happens to be the vehicle I use to extract content for web development. My main goal is usually the end result which usually portrays itself in the form of a web application or customer website.

For most of my career I’ve been working behind the scenes on the backend systems, but for a long time I’ve had an interest in web frontend technology. However, it seems that web frontend technology still isn’t taken all that seriously. HTML, CSS and JavaScript are considered technologies that you are expected to pick up as you go along and not really use a lot of time learning. To a certain extent this is true, but I still can’t help but find it odd that this is the case in 2008 considering just how much web development goes on in the world today. Your traditional senior programmer speaks in the language of design patterns and architecture, and although I can appreciate good backend architecture, I sometimes find the frontend a bit more fulfilling and challenging. Maybe because it’s easier to explain to to family and friends what I do for a living? Easier for them to visualize, I guess. 🙂

So, needless to say and according to my current interests, the last few months have been dedicated to working on web applications, creating company web sites and the like. At times it’s been great fun and I’ve learned a lot, especially about CSS which was something I always seemed to down prioritize and found “hard” to get comfortable with. I’m not sure what I really mean when I say “hard”, but for some reason I never really got in to it – mostly down to the fact that I had read a lot about it, but never really practiced it. I could never remember all the property names and their values, which is kind of half the point, I guess. This has now changed and within the last half year I have become more fluent in CSS and have grown to like it, and appreciated it’s power. I’ve also noticed just how bad it can get when more junior developers mess it all up, or don’t think in advance. The resulting CSS becomes a nightmare. I feel there is a great deal to be done on this frontier, but a lot of senior developers don’t want to touch it. Not challenging enough, I presume, which is a shame.

Projects
Just before the summer I got assigned to a project as a backend programmer. We were given the task of creating a company web site for a larger Norwegian gas company. The customer’s technology of choice was IBM’s Web Content Management (WCM). WCM, if you are unfamiliar, is a Java portlet based product that sits on top of WebSphere Portal Server. Although I had worked with both WebSphere Portal Server and WebSphere Application Server in the past, this was a different ball game.
We were two developers assigned to the project and luckily for me the other developer was fluent in CSS and other frontend technologies. He was a couple of years my junior, but I learned a lot from him. We both struggled with WCM at first and had to overcome a relatively high learning curve trying to find a good structure and extract our content before styling, but the end result was very good. The site looks beautiful today and the customer is happy. This was a relatively new experience for me in many ways. I don’t mean to offend anyone, but this was one of the first projects I was a part of where I actually felt I learned something of interest from someone else. Looking back, it was a great experience to follow a project from beginning to end and be part of the entire process. I’m not saying everything went smooth and we had our problems along the way, but in retrospect we did a good job. It’s just a shame the the technology, WCM in this case, is not much in use in my neck of the woods. However, HTML, CSS and jQuery parts, on the other hand, are. I also learned a bit about a few other web related things, like browser compatibility and became somewhat bemused that the tools for frontend technology development are still relatively poor. Was there really life before Firefox and Firebug?

The second project I was part of was to help refactor and expand a Java web application that is part of a company service desk for employee support. Although the technology in question was once again something odd, SAP EP using Java and SAP HTMLB in this case, I was happy to be able to introduce jQuery as a frontend alternative to help create some good looking stuff on the frontend. I was also happy to refactor some of the code, which was in dire need of some attention. Parts of it still is, I’m afraid. Old style JSP code with scriptlets etc. really do suck.

The third and final project I’ve been working on this autumn (and now nearly completed) is based on the open source Java portal, Liferay. Liferay has been a kind of baby of mine for the last 12 to 15 months. A colleague introduced me to it and ever since it seems I have been associated with the product, or at least that’s what everyone thinks at the company. In this project we created a web site for a customer to help their end users recycle materials and goods. We created a great deal of Java portlets in the process using Java, JSP and JSTL. We had to use a few of the new features of JSR-286 to get things working. In this project I also introduced jQuery into my frontend code which most certainly made some code a lot easier to both read and maintain. My CSS skills came in handy as well.

Conclusion
So there you have it and that’s it for now. A brief summary of what I’ve been up to for the past few months. Hopefully, I’ll have more for you soon, but don’t be surprised if it has more to with web development than backend programming, since that’s where my interests are at present. I’ve been reading a lot lately so expect a few book reviews soon. 🙂

Take care!