Deploying an app with static functions

The only thing that’s new here is the “myFunctions.tld” file. It has to be somewhere within WEB-INF or one of its subdirectories (unless it’s deployed in a JAR file, but we’ll talk about that later in the book). Here, because this app is so simple, we have both the DD (web.xml) and the TLD (myFunctions.tld) at the top level of WEB-INF, but you could organize them into subdirectories.

The key point is that the class with the static function MUST be available to the app, so... for now, you know that putting it inside WEB-INF/classes will work. And remember that in the taglib directive in the JSP, we specified a URI that matches the URI declared in the TLD. For now, think of the URI as simply whatever you decided to name the TLD. It’s just a name. In the next chapter on using custom tags, we’ll go into all the details about TLDs and URIs.

The class with the function (the public static method) must be available to the web app just like servlet, bean, and listener classes. That means somewhere in WEB-INF/classes...

Put the TLD file somewhere under WEB-INF, and make sure the taglib directive in the JSP includes a uri attribute that matches the <uri> element in the TLD.

There are no Dumb Questions

Q:
Q: A regular scriptlet expression MUST return something. If you say <%= foo.getFoo() %>, getFoo() must NOT have a void return type. (At least that’s what you said earlier.) So I’m thinking it’s the same with EL functions?
A:
A: No! It’s NOT the same with EL functions, although just about everybody finds that... surprising. Think about this—if you’re calling an EL function that doesn’t return anything, then you’re calling it just for its side effects! Given that part of the goal for EL is to reduce the amount of logic in a JSP (a JSP is supposed to be the VIEW!), invoking an EL function just for its side effects doesn’t sound like a good idea.
Q:
Q: How did the Container find the TLD? The URI doesn’t match the path or file name of the TLD. Was this a miracle?
A:
A: Just the question we were hoping someone would ask. Yes, you’re right—we never did tell the Container exactly where to find the real TLD file. When the app is deployed, the Container searches through WEB-INF and its subdirectories (or in JAR files within WEB-INF/lib) looking for .tld files. When it finds one, it reads the URI and creates a map that says, “The TLD with this URI is actually this file at this location...” There’s a little more to the story that we’ll cover in the next chapter.
Q:
Q: Can an EL function have arguments?
A:
A: Definitely. Just remember in the TLD to specify the fully-qualified class name (unless it’s a primitive) for each argument. A function that takes a Map would be:
<function-signature>
     int rollDice(java.util.Map)
</function-signature>
And call it with ${mine:rollDice(aMapAttribute)}

Watch it!

The METHOD name is not the same as the FUNCTION name!

Memorize the relationships between the class, the TLD, and the JSP. Most importantly, remember that the METHOD name does NOT have to match the FUNCTION name. What you use in EL to invoke the function must match the <name> element in the <function> declaration in the TLD. The element for <function-signature> is there to tell the Container which method to call when the JSP uses the <name>.

And the only place the class name appears (besides the class declaration itself) is in the <function-class> element.

Oh, and while we’re here... did you notice that everything in the <function> tag has the word <function> in it EXCEPT for the <name> tag? So, don’t be fooled by this:

The correct tag for the function name is <name>!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Deploying an app with static functions

Create new playlist

Sign In

Sign Up

Deploying an app with static functions

Watch it!

Table of Contents for
Deploying an app with static functions