2007-01-12

Email and Ajax

If you write a web form to allow people to compose a mail message and you intend to let them send the email once they are done... don't setup an Ajax method called "sendEmail" because... now you're asking for trouble. Especially if you are in a portlet and didn't extend security around the servlet that is servicing your JSON messages. Just not a great idea.

2007-01-11

Nobody gets CSS

Designers should "get" CSS. Yet of the dozen or so I've interviewed the following construct seems alien...

<div class="title">block1</div>
<div class="info"><div class="title">block2</div></div>
<div class="detail"><div class="title">block3</div></div>

Accompanied with the CSS that reads:

<style type="text/css">

.title {
background: red;
color: black;
}

.info .title {
background: blue;
}

.detail .title {
color: green;
}

</style>

Now I might ask...

What color is the text block1?
What color is the background?
And the same for block2?
And block3?

The answers are: block1 shows as black on red text, block2 shows as black on blue, and block3 shows as green on red. And most of my interviewees are utterly confused by the above code. Most will default to naming everything a unique name such as info_title and detail_title. This sort of defeats the purpose of having the classes and subclasses defined at all.

Why is this kind of construct more desirable than one unique name per block? In an Ajax application where items are being moved around the DOM you may want the block3 to transform properly when it is moved adjacent to the block2. Also there may be common properties between title blocks across the document... such as font and font size... and only certain properties are overloaded in certain contexts such as color.

2007-01-04

DWR POJO as a front controller for a WebService

In the past I would have written my own JavaScript using XmlHttpRequest and a servlet on the back end. This means I have to maintain a lot of code that has nothing to do with my specific project. I evaluated several Ajax frameworks and settled on DWR for my current project. But I have a problem.

I've been writing a DWR object to act as a front controller to a web service. As I wrote previously when using DWR you write a POJO. Register the POJO in dwr.xml and the annotations take care of the rest. But, what about request scope parameters? The request is gone by the time my POJO is called...

http://getahead.ltd.uk/dwr/server/javaapi

We use the WebContextFactory to pull out context data.

2007-01-03

@annotations

In case you've been under a rock... Java 5 now has a feature called the annotation and it allows you to attach meta-data to a class or a method. This isn't too terribly exciting unless you write a class that can read these annotations. Official docs here. So what I've found you end up doing is writing a proxy or mediator to handle how the annotated classes are used, what the annotations mean, and how the classes interact.

I'm using DWR at the moment and when we write a POJO and annotate it with the right annotations we get a class that DWR can use to create JSON messages. DWR searches a registered POJO for the "@RemoteMethod" annotations and registers those methods for remote invocation. This is very similar to how the JBossWS system works.

In both DWR and JBWS we are using annotations on POJOs to mark the class and method for consumption by a larger framework that will use the method we wrote to form the unique functional core of an application. We can tell the framework some things about how to consume the method and class using the annotation... and we can use the same POJO in multiple frameworks... in theory.

In theory the same annotations could mean different things to different frameworks. This way a POJO could be fed through a testing tool and then fed to a Web Services framework. The key to using the annotations is that the consuming tool, library, or framework sits across concerns from the POJO.

You POJO should be concerned about one thing, such as how to build an item summary. Your POJO then plugs into the framework. The result is that you program what is unique about your application and forget about everything else.

In designing tools, libraries, or frameworks to consume annotations, consider what is always the same. Write your framework to do those things. Then you register POJO into your framework to do the unique tasks for an application.

I can see a need for about a half dozen annotations frameworks from where I sit. And I can see how a code by convention system could be obsoleted by the astute use of annotations. If the framework is built intelligently, Java 5 could become the fastest and simplest way to build applications because so many concerns could be lifted from the application programmer's shoulders by use of Annotations and well-designed AOP.