Just give me a paragraph!

Question

The more I try to work with JSF (I'm trying to do things the JSF way, really, I am!), the more JSF doesn't want to work with me for simple things.
Let's just say I want to show the equivalent of the following HTML, but only if the user isn't logged in:
<p class="info"><a href="login.html">Log in</a> to see more data.</p>Simple, huh? Now, how do I do that in JSF? About the best I can do in JSF is this atrocious verbosity:
<html:panelGroup rendered="#{!user.loggedIn}">
     <jsf:verbatim>&lt;p class="info"&gt;</jsf:verbatim>
     <html:commandLink action="login">
          <jsf:verbatim>Log in</jsf:verbatim>
     </html:commandLink>
     <html:outputText value=" to see more data."/>
     <jsf:verbatim>&lt;/p&gt;</jsf:verbatim>
</html:panelGroup>I have to create a <html:panelGroup> because there's no JSF <p> component (to my knowledge).
I have to use the nested verbatim because I want to conditionally show the <p> tags along with the content. But in my XML source file, <jsf:verbatim> won't allow a nested beginning tags without ending tags, so I have to XML-escape my beginning <p> tag.
The nested <jsf:verbatim> inside <html:commandLink> certainly makes all this hard to internationalize, but I can live with that---it gets worse, though.
Outside <html:commandLink>, I have to use <html:outputText> because <jsf:verbatim>, because the latter trims off the beginning whitespace. However, I can't put the ending </p> tag literally here because the attribute can't have the less-than character ('<'). If I XML-escape the character, it comes out in the resulting file as escaped, and my XML is well-formed. So I have to put the extra <jsf:verbatim>.
Who knew a simple paragraph would take up so much of my time just to research how to do it in JSF? Now I'm taking more time researching whether it can be done better. Any suggestions? (I know, I can write a JSF <p> component...)

Answer 1

Why on earth didn't JSF provide this [HTML] functionality
with the reference implementation? I know Sun can't
provide everything, HTML equivalents are really
basic, and aren't rocket science.After more thinking and jumping into hard-core custom component development, I'm having some new thoughts---I'm understanding more the JSF architecural principles. This leads me to think that something like Sergey's very useful htmLib should not be included in the JSF API. Here's why.
First, I'm beginning to see where Hans Bergsten is coming from, when he recommends "Improving JSF by Dumping JSP" ( http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html ). I'm not quite ready to dump JSP, but the tight integration of JSF with JSP obscures the "JSF way" and makes it difficult for newcomers to adjust to its different paradigm.
Let me make an analogy with the Resource Description Framework (RDF) ( http://www.w3.org/RDF/ )---many newcomers have an extremely hard time understanding why RDF is useful or even different, because almost every discussion assumes that RDF is going to be serialized in XML. This in itself isn't so bad, but it leads newcomers to think of RDF as just another XML vocabulary. It's not. RDF is really an abstract framework for describing resources, resource properties, and the values of those properties (which can be other resources)---a framework for creating ontologies that, as some AI pundits would assert, can describe the world itself. XML provides a convenient syntax for serializing a directed graph of an RDF data model, but it produces no different semantics than limitless other syntaxes that could be invented and used to serialize RDF. (A Java properties file is one possible example that could produce a semantically identical RDF data model as could an XML serialization.)
Similarly, JSF is not just a way to write out HTML tags. It's actually a hierarchy of components that replicate the semantics of various data models and their interaction with a user. JSP is just one vehicle to do that; maybe it's not even the best. Maybe JSF is too closely tied to JSP, obscuring this revelation from users.
In this light, Sergey's HTML components have no place in the standard JSF API, because they function merely as a way for new users to quickly get a JSP page to write out a <p>, or a <ul>, or even a <table>. Sergey acknowledges as much: "The library allows you to use old-fashioned HTML layout tags ...., easing the transition to JSF for newbies." ( http://jsftutorials.net/htmLib/ )But the "JSF way" is to think in terms of JSF components implementing data models---whether they spit out XHTML or WAP or SGML is the responsibility of a plugable renderer, and should be distinct from the way the data is stored. htmLib is handy for newcomers and helpful when stuck in a bind and need to get a JSP generated, but designers creating large-scale, elegant JSF application architectures should be weaned away from thinking in terms of brute-force HTML tag writing.
My modification of viewpoint doesn't let JSF off the hook---indeed JSF should provide functionality out-of-the-box that, some way or another, can generate all desirable HTML tags. Instead of shallow wrapping classes, however, they should be robust, capable data model components with comprehensive default HTML renderers. Currently the dataTable component is about the only JSF component that provides a shadow of this concept, and in my opinion dataTable only allows about 70%-85% of needed functionality.
Take HTML <dl> (definition list) for an example. htmLib provides a great way for newcomers to write out an HTML definition list, and provides a teaching tool for learning component creation. The JSF standard component library, however, should provide a definitionList component that descends from UIData, allowing the component to be data-aware. A user should think in terms of an actual list model containing definitions. The definitionList should provide UIColumn descendants for "term" and "definition", and maybe even other columns. The default renderer for HTML would render a <dl> element, with <dt> for each term column child and a <dd> for each definition column child. (After a day of exploring custom component creation, I've just implemented such an animal as I've described.)
In the end, the functionality of such a definitionList with its default renderer is equivalent to htmLib:dl, but the semantics are different: an actual data model is described, and different renderers can be plugged in for other markup types.
Similarly, there should be some sort of text block data model with nestable children. There should either be a different UIComponent class for <p>, <blockquote>, and the like, or the component should indicate its semantics with, say, a semantics="paragraph" or semantics="blockquote" attribute.
In summary, Sergey's components are wonderful and very useful. I'm slowly coming around to the "JSF way," however, which leads me to conclude that, although JSF may need a paragraph data model component with a default HTML renderer, it doesn't need and shouldn't have a pass-through HTML <p> tag-writer such as htmLib provides. The difference is subtle, but paradigmatic.
Cheers,
Garret