Team. I have been thinking. There might be a better way of integrating the tile replacement content with the rest of the stencil. Consider this alternative for the exception XHTML that I placed online yesterday.
//BEGIN EXCEPTION XHTML
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>CABOOSE Embryo - Exception</title>
</head>
<body>
<!--
I chose that my tile replacement identifiers would
follow the pattern #ALL_CAPS_JAVA_IDENTIFIER#. This
is only a convention and not strictly enforced by the
cab. Obviously, the string used should not collide with
any other one that might be found in a markup document.
-->
<h1>EXCEPTION</h1></br>
<p>#EXCEPTION_MESSAGE#</p>
</body>
</html>
//END EXCEPTION XHTML
In this document, #EXCEPTION_MESSAGE#, is the tile replacement variable which will contain the exception message content provided this page is served up. The alternative is below:
//BEGIN EXCEPTION XHTML
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>CABOOSE Embryo - Exception</title>
</head>
<body>
<!--
I chose that my tile replacement identifiers would
follow the pattern #ALL_CAPS_JAVA_IDENTIFIER#. This
is only a convention and not strictly enforced by the
cab. Obviously, the string used should not collide with
any other one that might be found in a markup document.
-->
<h1>EXCEPTION</h1></br>
<p><tile class="cab.StencilHandler" method="exceptionRenderer"/></p>
</body>
</html>
//END EXCEPTION XHTML
Using the following approach would remove the need for the tile element in the directory XML file. This is the benefit of creating an evolving prototype and using the Bird-Foraging paradigm of programming. We can consider different ideas as they arise. There are a number of alternatives for implementing this. We could use an XML DOM reader and replace the tile elements in the page's document tree with a content node that comes from the rendering method. We also could use an XML SAX reader which echoes the content of the page replacing and tile elements with the rendered content when found. Also, JAVA Server Pages (JSP) and JAVA Server Faces (JSF) allow for the creation of custom tag libraries. One could create a tag which behaved as suggested above. This would integrate well both of these technologies and possibly simplify their use. Also, using a JSP or JSF custom tag would remove the need for keeping track of the view element in the directory.xml file. A custom tag implementation which used the SAX reader approach might be the cleanest, simplest, and most efficient solution; however, it might remove the need for the generic servlet since JSP and JSF pages eventually become servlets when compiled on first use. But, in retrospect, creating custom JSP and JSF tags plus a general-purpose servlet might be wise. We will consider all of these in the coming weeks.
Also, JSP and JSF already use the a concept called a "tile" which is a portion of the page's content. So, if we create a custom tile tag it must be in a unique namespace. Also considering the amount of progress which has been made in developing JSPs since 1999 and JSFs since 2003 plus the limits of my knowledge, this might already be available as a standard tag in one of those product. Obviously, one can use a JAVA Bean for supplying content on a page using JSP- or JSF-technology. So, we must do some more research on potential solutions before generating our requirement, specification, and design documents upon completion of this prototype. I would appreciate an suggestion or feedback with you might have in the forum at http://java.net/projects/caboose.
Also, I found a Bird Foraging Error in the source which I provided a few days ago. These things happen as code evolves. We had a method parameter for one of our modules which we never used. So, I removed it from the source which I will supply this week. I promise that I will do more thinking and less pecking in the future. Enjoy the rest of your day. La-La.
No comments:
Post a Comment