What is the Logic for splitting the JSF Core and HTML tag libraries?

[Cameron Wallace McKenzie]

I'm just looking at the JSF Core and JSF HTML tag libraries, and wondering what the logic was in the way tags were split up.

I guess initially, you'd say the HTML tags map directly to HTML elements, but that's only half the truth. Tags like message and messages don't really map to any HTML tag.

And in the core, we see things like selectItem and selectItems, which do map directly to HTML elements. Why aren't they in the HTML library?

I guess any markup, not just HTML, might have selectItems or selectItem elements in the GUI, so that's why these are in core. But then, every markup language would need messages too, so shouldn't messages go into core?

I'm not complaining or being a sour puss. I'm just wondering if there is actually a good, clear, delineating line of reasoning that I can use when describing the difference between the two libraries; a definition that would easily explain selectItem in core, and messages in HTML.

Here's a listing of which tags are in which Java Server Faces tag library, just in case you haven't brushed up on your JSF in a while.

I'm happy to entertain guesses or opinions that would make sense. Don't feel you need to quote the JSR docs.


CORE:

actionListener : attribute : convertDateTime : converter : convertNumber : facet : loadBundle : param : selectItem : selectItems : subview : validateDoubleRange : validateLength : validateLongRange : validator : valueChangeListener : verbatim : view

HTML:

column : commandButton : commandLink : dataTable : form : graphicImage : inputHidden : inputSecret : inputText : inputTextarea : message : messages : outputFormat : outputLabel : outputLink : outputText : panelGrid : panelGroup : selectBooleanCheckbox : selectManyCheckbox : selectManyListbox : selectManyMenu : selectOneListbox : selectOneMenu : selectOneRadio

-Cameron McKenzie

[Tim Holloway]

I'm glad to see you know that JSF isn't just a fancy form of HTML. So few people do.

Addressing the items you've boldfaced:

- The JSF View is basically just the top-level container for any presentation view. I'm not even sure it generates any HTML at all. But just try omitting it! So of course subview would also carry over.

- You've already mad the case for selectItem(s). They're data interfaces. How they get displayed depends on their containing UI object, just as is the case with facet.

- Form might seem more abstract, as a container for UI objects. But its actual behavior is pretty firmly bound to how a raw HTML FORM acts. Since it is, in fact a UI container in any event, it's not unreasonable that it be in the HTML tag collection.

- It's true that messages are pretty universal, but the JSF messages are more specific. Firstly, the message "for=" form is inherently attached to an HTML form control, so it wouldn't be a good fit for the underlying core tagset. Secondly, the "messages" tag carries display options with it (bullet/table). In other words, presentation-specific stuff.

So, in short, the core tags are all abstractions and facilitators. The HTML tags are all geared towards a specific primary renderer.

Some things could have been done differently. If JSF carried the abstract concept of a table (that is, a 2-dimensional matrix) in the core, for example, then it would be reasonable for there to be a core column tag as well. Although having an html-specific column tag would still be permissible if it provided HTML-specific extensions to the core concept. It's very common for third-party tagsets to augment the HTML datatable tag and its contained element types, for example.

[Cameron Wallace McKenzie]

So, in short, the core tags are all abstractions and facilitators. The HTML tags are all geared towards a specific primary renderer.

I think that sounds very smart and provides a very elegant explanation. Thanks!

-Cameron McKenzie