Enterprise data used in the web tier is increasingly XML these days
whether the enterprise data is a response coming from a Web Service, the result
of a stock quote from Nasdaq, a google search, babel fish translation, an Amazon
book search, NewsML news articles, or RSS for content syndication. When companies
cooperate over the web, XML is the data format of choice for exchanging information.
XML is therefore becoming more and more important in a page author's life. The set of XML tags specified in JSPTL is therefore meant to address the basic XML needs a page author is likely to encounter.
A key aspect of dealing with XML documents is to be able to easily access their content. XPath, a W3C recommendation since 1999, provides an easy notation for specifying and selecting parts of an XML document. The XML tagset in JSPTL is therefore based on XPath.
For the XPath challenged, here are a few links to get you started quickly:
It is important to note that the Expert Group is still debating which global Expression Language(s) will be officially supported by JSPTL. While this discussion is still taking place, the approach we've taken here is to consider XPath as a local Expression Language that applies to the XML tagset. How this local XPath Expression Language integrates with the Global Expression Language as well as JSP.next is briefly discussed in this document.
The assumption is that if XPath (or a derivative) is not selected as the
or one of the Global Expression Languages, this set of tags would probably
stay as is. If XPath were to become one of the Global ELs, the design
of these tags would probably change, the extent of which has not yet been addressed.
What we're doing with our set of XML tags is expanding our notion of Expression Language so it can also apply "locally" to tags that want to support an EL that is not the global one(s) supported within JSPTL.
Below are the rules of integration that XPath follows as a local EL, so we have the guarantees that it plays nicely within the JSP/JSPTL environment.
Attributes to specify XPath Expressions
In the JSPTL set of XML tags, XPath expressions are always specified using attribute "select". This therefore means that only values specified for "select" attributes are evaluated using the XPath expression language. All other attributes are evaluated using the rules associated with the currently active global Expression Language. This should help avoid confusion between XPath and the global Expression Language.
XPath Variable Bindings
JSPTL supports variables in XPath expressions. The mapping of XPath variable expressions is defined as follows:
$foo |
maps to pageContext.findAttribute("foo") |
$page:foo |
maps to page scope |
$request:foo |
maps to request scope |
$session:foo |
maps to session scope |
$app:foo |
maps to application scope |
$param:foo |
maps to request.getParameter("foo") |
$initParam:foo |
maps to request.getInitParameter("foo") |
$cookie:foo |
maps to the cookie's value for name foo |
$header:foo |
maps to request.getHeader("foo") |
Through these mappings, scoped attributes, parameters, headers, and cookies can all be used inside XPath expressions easily. For example:
/foo/bar[@x=$param:name]
would find the "bar" element with an attribute "x" equal
to the value of the http request parameter "name".
Context Setup
The context for the evaluation of an XPath Expression can be set in one of two ways; either directly within the XPath expression:
<x:parse source="$xml" var="doc"/>
<x:expr select="$doc/..."/>
or via an ancestor tag that sets a context that can be applied to its nested tags. In the example below, the XPath expression specified in the select attribute of <expr> has its context set to the current "atom" node in the document.
<x:forEach select="$doc//atom"/>
<x:expr select="name"/>
<x:forEach/>
As mentioned in the previous section, only the "select" attribute of xml tags can take XPath expressions. Global EL expressions and XPath expressions cannot be mixed in the "select" attributes.
With JSPTL 1.0, the xml tagset knows that the value of select attributes are XPath expressions. However, things will be different in JSP.next when the evaluation of 'elexprvalues' are handled directly by the container. If the metacharacter used to identify an 'elexprvalue' is defined as '$', this means that XPath expressions starting with a variable would have to be escaped in a JSP.next environment, unless JSP.next has provisions in the TLD to prevent expression evaluation.
There might be other issues. These will be addressed once the discussions on the Expression Language resume.
The <parse> action parses an XML document and saves the resulting object in the JSP scoped attribute specified by attribute "var". The type of the resulting object is not defined by the spec to allow implementations to use whatever they deem best for efficient implementations of the XML tagset.
The XML document can be specified either via the "source" attribute (String or Reader object)
<jc:import url="http://acme.com/athletes?country=ethiopia" var="xml"/>
<x:parse source="$xml" var="athletes"/>
or inline via the tag's body content:
<x:parse var="athletes"> <athletes> <athlete> <name>Abebe Bikila</name> <country>Ethiopa</country>
</athlete> <athlete> <name>Mamo Wolde</name> <country>Ethiopia</country>
</athlete> </athletes> </x:parse>
When used in conjunction with the <parse> tag, the JSPTL core tag <import> provides access to a wide variety of URL-based input resources representing XML documents.
It is also possible to force the <parse> action to expose an XML Document (org.w3c.dom.Document) by specifying "domVar" instead of "var" (mutually exclusive). This would be useful in situations where custom actions are developed to act on XML documents. Since it is not a requirement for the implementation to support its own internal data structures, it may therefore be the case that "var" exposes the same object as "domVar".
If an implementation of the XML tagset is based on DOM-like structures (check with the specific implementation you're using), there will be a significant performance impact when dealing with large XML documents. To help with this, attribute "filter" can be used to allow filtering of the input data prior to having it parsed by the implementation into a DOM-like structure.
For example, if one is interested in processing only the "European" customers which represent only 10% of the original XML document received as input, it will greatly reduce the size and complexity of the resulting DOM structure if all non-European customers are pruned from the XML document prior to parsing.
<jc:import url="http://acme.com/customers" var="xml"/>
<x:parse source="$xml" filter="$filterEuropeanCust" var="doc"/>
The "filter" attribute accepts an object of type org.xml.sax.XMLFilter
.
If configuration of the filter is desirable, it is suggested that the developer of the filter provide a custom tag for easy configuration by a page author.
<acme:myFilter var="filter" xpath="//author" ... />
<x:parse filter="$filter" .../>
The <expr> action evaluates the given XPath expression on the current
context node and outputs the result of the evaluation to the current JspWriter
object. It is the equivalent of <%= %> and <jc:expr>
,
with the difference that it is meant for the XPath Expression Language world
(as opposed to the scripting language world (<%= %>
) and
the Global Expression Language world of JSPTL <jc:expr>
).
The expression to be evaluated is specified via the attribute "select" and must be in the XPath syntax. The result of the evaluation is coerced to a String and is subsequently emitted into the current JspWriter object.
For example:
<x:expr select="$athletes/athlete/name"/>
The <set> action evaluates an XPath expression (attribute "select") and sets the result into a JSP scoped attribute specified by attribute "var".
In this first example, the list of athletes from a specific country is saved in scoped attribute athletesOfCountry:
<x:set select="$athletes/athlete[country=$request:country]"
var="athletesOfCountry"/>
In this second example, the <set> action is used to set a context used by other xml tags:
<x:set select="$athletes/athlete[id=$param:athleteId]" var="ath"/> <x:expr select="$ath/name"/>
<x:expr select="$ath/country"/>
Some XPath expressions can be evaluated without a context
For example:
starts-with($header:user-agent,
'Mozilla 4.0')
XML Core Tags | |
Element | Sample usage |
<parse> var domVar
source filter Parses an XML and saves its internal representation into the JSP scoped attribute specified by "var" (or "domVar"). |
<c:import url="http://acme.com/athletes?country=ethiopia"
var="xml"/> |
|
|
|
<x:set |