You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

FreeMarker tags are extensions of the generic Tags and UI Components provided by WebWork. You can get started almost immediately by simply knowing the generic structure in which the tags can be accessed: <@ww.xxx> ...</@ww.xxx>, where xxx is any of the tags supported by WebWork.

Syntax

For example, in JSP you might create a form like so:

<ww:form action="updatePerson">
    <ww:textfield label="First name" name="firstName"/>
    <ww:submit value="Update"/>
</ww:form>

In FreeMarker the same form is built like so:

<@ww.form action="updatePerson">
    <@ww.textfield label="First name" name="firstName"/>
    <@ww.submit value="Update"/>    
</@ww.form>

While this covers almost all know need to know for for FreeMarker tags, there are a few other advanced features you should read about, specifically with how attributes and parameters work together, and how attribute types (String, List, etc) can affect the tag behavior.

Attributes and Parameters

Unlike older versions of JSP (in which the JSP Tags are based), FreeMarker allows for dynamic attributes, much like JSP 2.0. What this means is that you can supply attributes to the tags that the tag doesn't even support. Those attributes that cannot be applied directly to the tag object will instead be set on the tag's general parameters map.

For example, suppose you have the following code in JSP:

<ww:url value="somePage">
    <ww:param name="personId" value="%{personId}"/>
</ww:url>

In FreeMarker, you can simplify this as:

<@ww.url value="somePage" personId="${personId}"/>

In addition to being able to replace cases where you might use the param tag, you can also use this functionality when building additional templates or themes for your Form Tags. For example, suppose you created a "three column" theme to replace the typical two column theme (xhtml). You might want an additional parameter to display in the third column called "description". Your form can be:

<@ww.form action="updatePerson">
    <@ww.textfield label="First name" name="firstName" description="..."/>
    <@ww.submit value="Update"/>    
</@ww.form>

And then in your new template you can refer to the description using ${parameters.description}.

Sometimes you may still wish to use the param tag, such as when you are nesting complex HTML within tags. The param tag has support beyond what FreeMarker can provide as inline attributes: it can take the entire body of the param tag and apply that as the value attribute.

Attribute Types

Remember that all tag attributes must first be set as Strings – they are then later evaluated (using OGNL) to a different type, such as List, int, or boolean. This generally works just fine, but it can be limiting when using FreeMarker which provides more advanced ways to apply attributes. Suppose the following example:

<@ww.select label="Foo label - ${foo}" name="${name}" list="%{{1, 2, 3}}"/>

What will happen here is that each attribute will be evaluated to a string as best it can. This may involve calling the toString() method on the internal FreeMarker objects in the hash. In this case, all objects will end up being exactly what you would expect. Then, when the tag runs, the list attribute will be converted from a String to a List using OGNL's advanced collection support.

But suppose you wish to use FreeMarker's list or hash support instead? You can do this:

<@ww.select label="Foo label - ${foo}" name="${name}" list={1, 2, 3}/>

Notice that the list attribute no longer has quotes around it. Now it will come in to the tag as an object that can't easily be converted to a String. Normally, the tag would just call toString(), which would return "[1, 2, 3]" and be unable to be converted back to a List by OGNL. Rather than go through all this back and forth anyway, the FreeMarker tag support within WebWork will recognize collections and not pass them through the normal tag attribute, but instead set them directly in the parameters map, ready to be consumed by the template.

In the end, everything tends to do what you would expect, but it can help to understand the difference of when OGNL is being used and when it isn't, and how attribute types get converted.

  • No labels