Blogs

Use proper case for JSP tag attributes

Igor Spasić

November 24, 2010

A Minute Read

Remember:

For JSP tags with dynamic-attributes, be careful to use proper case of defined attribute names; especially if scriptlets are used as attributes values.

Look at following two usages of button tag of liferay-aui tag library:

(A)

<aui:button onclick="<%=target%>" value="some value" />

(B)

<aui:button onClick="<%=target%>" value="some value" />

On the first sight there is no difference, as it is no difference in HTML. But lets dig deeper.

In (A) we set the 'onclick' attribute. Quick look into the aui TLD tell us that there is no such attribute; instead there is 'onClick'. Now, what (some?) servlet containers will do? They will assume that 'onclick' is a dynamic attribute; it will be set dynamically in the tag instance; not using the existing setter method. Obvious drawback is performance loss, since no simple setter method is used. Therefore, execution of (A) is slower.

But its not only the performance what is hurt. On some servers, such as Websphere 6, usage of tag when dynamic attribute is used (as in example A) is encapsulated in separated method of the generated jsp class. Unfortunately, scriplet variable will not be passed to this method, although it will be used in the methods code for setting the value - that combination gives us the compile error! I agree, this might be the app server bug, but we still have the jsp compile error to deal with.

To summarize the drawbacks of not using the proper attribute name case:

execution is slower
jsp will not compile on some servers if scriptlet is used as attribute(s) value.

So, please, stick with the (B)

7 Comments

Please sign in to comment.

Nice information. Good that i dont remember tld attributes and everytime i copy it from tld and place it in the tag. Didnt ever knew it saved me from above two problems emoticon

Please sign in to reply.

Fortunately, my IntelliJ gives me attributes autocomplete, so i also never thought about this before;)

Please sign in to reply.

Nice! Thx for useful information. Maybe you know, which servers use (A) example as dynamic attribute?

Please sign in to reply.

Thats up to the enterprise/web application installed in the server emoticon

So it depends on deployed applications, how they have been written.

Furthermore, servers compile JSPs differently. In most servers, using (A) with dynamic attributes will not give the error. But some, such as WebSphere 6 will fail and give jsp compile errors.

Please sign in to reply.

Sory for my vague question. My question was: which servers use (A) example as dynamic attribute and which give me 'compilation error'. I test it on Tomcat and JBoss and that not give me the error, but when I use (A) version I really get my value in dynamicAttributes map. Forget about my question emoticon

Please sign in to reply.

Why did you guys choose camel-case over all lowercase like xhtml's onclick?

Please sign in to reply.

i don't know... or the legacy code emoticon

anyway, one thing is the format of jsp page and the the other thing is the format of generated markup code. so even if taglibs are in camelCase, they could produce the markup code that is lowercase and more xhtml friendly emoticon

still, this is probably not the only thing that has to be changed to have fully xhtml output.

I believe that HTML5 is our main focus now and that standard is less restrictive.

(Of course, all this is just a personal view, not an official statement;)

Please sign in to reply.