Servlets & JSP Series 9 - Custom tags are powerful

 

Servlets & JSP Series 9 - Custom tags are powerful

 

• Using the c:out tag to render the text of users prevents cross-site hacking of this form by displaying the <script> tags and the JS code in other user’s web browser, this prevents the JS code from being interpreted by the browser, foils the attack from the user.
• <c:out> also can set default value with the default attribute.
• <c:forEach> tag from the JSTL is perfect – it gives us a simple way to iterate over arrays and collections.
• The <c:forEach> tag maps nicely into a for loop – the tag repeats the body of the tag for each element in the collection ( and we use “collection” here to mean either an array or Collection or Map or comma – delimited String), the key feature is that the tag assigns each element in the collection to the variable you declare with the var attribute, varStatus makes a new variable that holds an instance of java.servlet.jsp.jstl.core.LoopTagStatus, the LoopTagStatus class has a count property that gives you the current value of the iteration counter.
• Also we can even nest <c:forEach> tags.
• The <c:choose> tag and its partners <c:when> and <c:otherwise> can be used when you need an else.
• The <c:set> tag is much cooler than <jsp:setProperty>, it can set a value in a Map; set comes in two flavors: var and target. The var version is for setting attribute variables, the target version is for setting bean properties or Map values, each of the two flavors comes in two variations: with or without a body, the <c:set> body is just another way to put in the value, if the value evaluates to null, the variable will be removed.
• Key points and gotchas with <s:set> : 1.You can never have both the “var” and “target” attributes in a <c:set>; 2.”Scope” is optional, but if you don’t use it the default is page scope; 3.If the “value” is null, the attribute named by “var” will be removed; 4.If the attribute named by “var” does not exist, it will be created, but only if “value” is not null; 5.If the “target” expression is null, the Container throws an exception; 6.The “target” is for putting in an expression that resolves to the Real Object, if you put in a String literal that represents the “id” name of the bean or Map, it won’t work, in other words, “target” is not for the attribute name of the bean or Map – it’s for the actual attribute object; 7.If the “target” expression is not a Map or a bean, the Container throws an exception; 8.If the “target” expression is a bean, but the bean does not have a property that matched “property”, the Container throws an exception, remember that the EL expression ${bean.notAproperty} will also throw an exception.
• <c:remove> is used for removing an attribute.
• The <c:import> JSTL tag dynamically adds the content from the value of the URL attribute to the current page, at request time, it works a lot like <jsp:include>, but it’s more powerful and flexible.
• The differences of three ways to include content: the include direction; the <jsp:include> standard action; the <c:import> JSTL tag – Each of the three mechanisms for including content from another resource into your JSP uses a different word for the attribute, the include directive uses file, the <jsp:include> uses page, and the JSTL <c:import> tag uses url, this makes sense, when you think about it, but you do have to memorize all three, the directive was originally intended for static layout templates, like HTML headers, in other words, a “file”, the <jsp:include> was intended more for dynamic content coming from JSPs, so they named the attribute “page” to reflect that, the attribute for <c:import> is named for exactly what you give it – a URL, remember, the first two “include” cannot go outside the current Container, but <c:import> can.
• With <jsp:include> or the include directive, we can include only pages that are part of the current web app, but now with <c:import>, we have option to pull in content from outside the Container.
• Session tracking happens automatically with JSPs, unless you explicitly disable it with a page directive that has a session attribute that says session = “false”; <c:url> tag dose URL rewriting automatically.
• isErrorPage = “true” confirms this page is an officially – designated error page.
• We can declare error pages in the DD for the entire web app, and we can even configure different error pages for different exception types, or HTTP error code types, the container uses <error-page> configuration in the DD as the default but if a JSP has an explicit errorPage page directive, the Container uses the directive.
• If you have a page that invokes a risky tag, but you think you can recover, there’s a solution, you  can do a kind of try/catch using the <c:catch> tag, to wrap the risky tag or expression.
• We can make the exception an attribute, using the “var” attribute in <c:catch> if you want to access the exception after the end of the <c:catch> tag, it puts the exception object into the page scope, under the name you declare as the value of var.
• Flow control works in a <c:catch> the way it does in a try block – nothing runs inside the <c:catch> body after the exception. A <c:catch> acts more like a try block, because it’s where you put the risky code, except it’s like a try that never needs a catch or finally block.
• JSTL have 5 libraries – four with custom tags, one with a bunch of functions for String manipulation: 1.The “Core” library; 2.The”Formatting” library; 3.The “SWL” library; 4.The “XML” library.
• To use a custom library, you must read the TLD, everything you need to know is in there, main things you have to know: 1.The tag name and syntax; 2.The library URI.
• <jsp:attribute> lets you put attributes in the body of a tag, even when the tag body is explicitly declared “empty” in the TLD.
• A tag can have a body only if the <body-content> element for this tag is not configured with a value of empty, the <body-content> element can be one of either three or four values, depending on the type of tag.
• The tag handler developer creates the TLD to tell both the Container and the JSP developer how to use the tag, a JSP developer doesn’t care about the <tag – class> element in the TLD, that for the Container to worry about, the JSP developer cares most about the uri, the tag name, and the tag syntax.
• The taglib <uri> is just a name, not a location, the <uri> element in the TLD is a unique name for the tag library, it does not need to represent any actual location, it simply has to be a name -  the same name you use in the taglib directive.
• The Container looks for a match between the <uri> in the TLD and the uri value in the taglib directive, the uri does not have to be the location of the actual tag handler.
• The Container searches in several places to find TLD files – we do not need to do anthing except make sure our TLDs are in one of the right locations: 1.Directly inside WEB-INF; 2.Directly inside a sub directory of WEB-INF; 3.Inside the META-INF directory inside a JAR file that’s inside WEB-INF/lib; 4.Inside a sub-directory of META-INF inside a JAR file that’s inside WEB-INF/lib.