Tag design advice

[John Hyde]

I'm trying to design a tag which queries data from a cache, restructures the data and writes a html table from data using jstl tags.

So the .tag file looks like:

<%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<jsp:useBean id="metaCache" class="com.abc.vendor.MetaCache" scope="application" />

<%@attribute name="name" required="true" %>
<%@attribute name="source" required="true" %>

<%
  java.util.Set<com.abc.vendor.CacheEntry> cachevalue= metaCache.getDeviceDetails(name, source);

  // java code to restructure the complex cache values using maps, lists etc
  // i.e decompose them into simple collections
  // so it's easier for the jstl tags to work with
  // ....

  jspContext.setAttribute("cachevalue", cachevalue);
%>

<!-- write html content using JSTL tags to read the jspcontext cachevalue -->
<c:forEach .....
....

The device has two kinds of data, metadata where it tells what kind of data I'll be receiving, which I'll be storing in a local database and the actual data which is received from the device whose format is as expected from the metadata. So the above cache query is a metadata cache query, not the actual data coming from the device.

Is this approach acceptable? Is it right to query the device cache using scriptlet code?
If not, what would be the best solution to these kind of problems? Is it possible to associate both a .tag file and java file to this tag so that I can separate the java logic to the java class?

[Bear Bibeault]

I personally would not use scriptlets. I'd create a bean that handled anything that can't be handled by the tag file body.

[John Hyde]

Bear Bibeault wrote:I personally would not use scriptlets. I'd create a bean that handled anything that can't be handled by the tag file body.

I'm fairly new to tags, so a tag can have a java class associated to it (<tag-class>) and can also have a tag body in the .tag file?

[Bear Bibeault]

What I've done in the past, is to use <jsp:useBean> in the tag (one of the only useful remaining uses for useBean in the post-scriptlet era) and then set the pageContext into the bean so it can have access to the environment. I fancifully called such "helper beans" tag valets.

The <c:set> action is useful for setting the pageContext property.

[John Hyde]

Bear Bibeault wrote:What I've done in the past, is to use <jsp:useBean> in the tag (one of the only useful remaining uses for useBean in the post-scriptlet era) and then set the pageContext into the bean so it can have access to the environment. I fancifully called such "helper beans" tag valets.

The <c:set> action is useful for setting the pageContext property.

I think this is similar to what you said in 2005, https://coderanch.com/t/288268/JSP/java/taglib-JSP-tagfile , any chance that faq has been written?

[Bear Bibeault]

Heh.... I never got around to writing that FAQ. It's pretty simply though.

Define the bean to have a pageContext property, and use the "target" version of <c:set> to set it (after the useBean to create the bean in the first place).

I'll see if I can dig up an example in my older code.

[Bear Bibeault]

In fact, here's an abstract class I set up to extend to create a "valet":

package putyourpackagenamehere;

import javax.servlet.jsp.PageContext;

/**
 * Abstract base for implementing "page valet" view helpers.
 */
public abstract class AbstractPageValet {

  private PageContext pageContext;

  public PageContext getPageContext() { return this.pageContext; }
  public void setPageContext(PageContext pageContext) { this.pageContext = pageContext; }

}

[John Hyde]

Bear Bibeault wrote:In fact, here's an abstract class I set up to extend to create a "valet":

package putyourpackagenamehere;

import javax.servlet.jsp.PageContext;

/**
 * Abstract base for implementing "page valet" view helpers.
 */
public abstract class AbstractPageValet {

  private PageContext pageContext;

  public PageContext getPageContext() { return this.pageContext; }
  public void setPageContext(PageContext pageContext) { this.pageContext = pageContext; }

}

Thank you for digging that out, but I don't understand how you go about calling a specific functionality in that new class.
What I understand is.

tagFile:

  useBean -> CustomClass
  set pageContext to CustomClass

  <!-- How to make the CustomClass do work and set the result to passed pageContext?? -->
 
  JSTL soup

[Bear Bibeault]

Looking at your original code, I'd create a method in the bean such as getCacheValue() that would perform the work that you are currently doing in the scriptlet, and returns the set of CacheEntry instances as the result.

Then, (assuming you have created the bean with id cacheValueValet) -- see below -- you can simply cause it to be invoked with ${cacheValueValet.cacheValue}. This will evaluate to the Set.

Not only does this eliminate grody scriptlets, it makes the code much more succinct.

The code to create the "valet" (from memory so may need adjusting), would be along the lines of:

<jsp:useBean class="whateverpackage.CacheValueValet" scope="page" id="cacheValueValet"/>
<c:set target="${cacheValueValet}" property="pageContext" value="${pageContext}"/>

In fact, because your code doesn't need the page context at all, you could skip setting it. (Most page helper beans would likely need the context.)

[John Hyde]

Bear Bibeault wrote:Looking at your original code, I'd create a method in the bean such as getCacheValue() that would perform the work that you are currently doing in the scriptlet, and returns the set of CacheEntry instances as the result.

Then, (assuming you have created the bean with id cacheValueValet) -- see below -- you can simply cause it to be invoked with ${cacheValueValet.cacheValue}. This will evaluate to the Set.

Not only does this eliminate grody scriptlets, it makes the code much more succinct.

The code to create the "valet" (from memory so may need adjusting), would be along the lines of:

<jsp:useBean class="whateverpackage.CacheValueValet" scope="page" id="cacheValueValet"/>
<c:set target="${cacheValueValet}" property="pageContext" value="${pageContext}"/>

In fact, because your code doesn't need the page context at all, you could skip setting it. (Most page helper beans would likely need the context.)

Thanks for the code snippets, but in the end I chose EL functions, they seemed to be even more cleaner

[Bear Bibeault]

Heh heh... that's the next thing I was going to mention. Kudos for beating me to the punch!