 |
|
   |
|
|
 |
By Luca Passani
The Java Standard Tag Library (JSTL) offers an elegant way to implement programming logic in your JSPs while using a declarative tag-based syntax. This goes a long way in keeping your JSPs tidy and readable. We have already touched on JSTL in the third and fourth part of this tutorial (Cool Menus and Forms). A lot of the JSTL is intuitive enough that the little JSTL we showed did not need much explanation. However there is much more to JSTL than what we saw there. An in-depth discussion of JSTL would be way out of scope for this article, but there's plenty of articles, tutorials and books out there (see references). JSTL includes tag-libraries to support common, structural tasks such as iteration and conditionals, tags for manipulating XML documents, internationalization tags, and tags for accessing databases using SQL. Central to JSTL is the concept of Expression Language (EL) which WALL exploits to make WURFL capabilities accessible with a syntax as simple as ${capabilities.screen_width}.
In addition to the elegance of the tags, the "standard" term in the acronym signifies that you can port your JSTL-based JSP pages to any JSP container and legitimately expect them to work (while giving the different JSP containers a chance to optimize the support for the tags). The links in the reference lead to JSTL tutorials and resources. This article provides an example of how JSTL and WALL can be used together to address some very real issues specific to development for the wireless web. How Far Can WALL Abstractions go? We need to take a step back and think about what WALL does at a higher level. Wireless browsers support different mark-ups and even render the same mark-up differently. WALL is about abstracting away those differences. Not all abstractions are born equal, though. Some abstractions are fairly straightforward, while others are more complex. Take 'Menus', for example: Not only do they solve an obvious problem, but they are also pretty intuitive to figure out and use. This is not the case for all the abstractions: some are smart, but they require the programmer to make a little effort to understand the rationale behind their use and their syntax. 'Forms' and 'Cool Menus' are good examples of such useful abstractions which demand slightly more effort to grasp. As we create more (and more complex) abstractions, we find ourselves pretty quickly into 'diminishing returns': lots of extra effort for abstractions that are hard to understand and use. A great example of a possible abstraction was provided by a question posted on the WMLProgramming mailing list just this morning (June 22, 2005): "Is there any possibility to redirect a page or URL from WALL ?" The answer could be yes or no depending on how you look at it. The answer is "no" because WALL does not implement any abstraction that will make any browser jump to a given URL automatically. In the opinion of the WALL author, creating such an abstraction would not make sense in practice. Many cases are simple enough to work around, that developers will find the best solution autonomously. In this case, for example, JSPs could just recognize WML browsers (i.e.: ${capabilities.wall_markup == 'wml'}) and create an
onenterforward event for them, while other browsers would get
a META tag to achieve the same result.
In other words, there is a workaround that is simple enough to
demote the creation of an ad-hoc abstraction.
Because of this, the answer to the question above could legitimately be "yes,
redircting in WALL is, indeed, possible".
Bottom line is: there is no reason to stuff WALL
with tens of abstractions. They would be too specific, while
in most cases, the same solution can be easily achieved with
tiny local "branchings" in your JSPs. In real cases, application developers
can make assumption over the context of their application that the
WURFL and WALL creators could not make when designing a general pourpose tool.
In those cases, developers can exploit their 'domain knowledge' to optimize their
application for their real user base.
In this context, JSTL offers a great way to implement and menage domain-specific
logic in a compact and intellegible way.
Time for an example Imagine you have a website which uses two main colors, say blue and orange, as an integral part of corporate identity. Because of all of the cool new color device around, it only makes sense to use the same colors in your wireless pages. Once you introduce CSS info in our page, you would legitimately expect the page to look something like Figure 1:  Figure 1: You expect to see something like this on all XHTML devices This will in fact work on some devices. On other devices, though, what you see might be different and look something like Figure 2:  Figure 2: What you might get on some devices. What happens is that the background color is not what you thought it was and the CSS values for the links is completelly ignored. If you wonder how this is possible, consider that:
One possible solution to this problem could come from using the JSTL and the patch file. We decide that the default colors for our WAP site are the very safe black and white, but, at the same time, we reserve the right to use the proper company colors on devices which are known to bahave. Let's start by defining two application-specific capability names: myapp_text and myapp_bgcolor We proceed to generate a patch_file that defines the new capabilities (Listing 1). By setting the values of the capabilities to black (RGB=#000000) and white (RGB=#FFFFFF) in the 'generic' device, we effectively set the default. We can now go on to set the corporate colors for devices we consider safe (all Nokia Series 60 devices and Sharp GX30, just for sake of example in the article. In practice, there are many more): The power of all of this becomes obvious when you look at what you can do in your JSP pages (this JSP is for Tomcar 4. Tomcat 5 users please look at the note at the end of this article): The result is shown in Figure 3:  Figure 3: Different devices get different treatment depending on logic that is totally specific to your application. Describing the code in Listing 2 is, at this point, little more than a formality. - line 5: use the 'load_capabilities' tag to import all of the WURFL capability/value pairs into the JSTL EL. This is what makes the ${capabilities.capability_name} syntax possible. - line 8 through 12: if we are dealing with a XHTML-MP device and this device is not using the default black/white colors, then create a CSS that will make links the color of text (also a WURFL capability). - line 14: use the text and background colors that were defined in the patch file for this device. - line 17 and 18: spell out device model name and brand (also WURFL capabilities) here is the mark-up returned for a Series 60 device (listing 3) and one (listing 4) that is not marked as color-safe in the WURFL patch: Note about JSTL and Tomcat 5 If you are doing your tests on Tomcat 5, an extra more compact syntax is supported for JSTL EL (Expression Language). This is a consequence of the fact that Tomcat 5 supports JSP 2 and JSTL 1.1. The differences in Listing 5 (as compared to Listing 2) are:
Conclusions WALL supports a lot of useful abstractions, but there comes a time when the developer has to step in and fine-tune their application according to their specific needs. After all, nobody knows their application better than the developer itself. When the time comes, WURFL, JSTL and EL help introducing ad-hoc logic while keeping your JSPs self contained and manageable. Tutorial part 5 is the last one in the tutorial series. References JSTL Links jakarta.apache.org/taglibs/doc/standard-doc/intro.html JSTL Tutorials java.sun.com/webservices/docs/1.0/tutorial/doc/JSTL.html java.sun.com/webservices/docs/1.1/tutorial/doc/JSTL.html WURFL Patch File wurfl.sourceforge.net/patchfile.php |