jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] javax.faces.view.facelets.TagDecorator

From: Leonardo Uribe <lu4242_at_gmail.com>
Date: Mon, 18 Jun 2012 11:59:08 +0200

Hi

Reading some stuff related to JSF spec, I notice something odd in the spec.

Take a look at this class

http://javaserverfaces.java.net/nonav/docs/2.1/javadocs/javax/faces/view/facelets/TagDecorator.html

TagDecorator is an interface that comes from facelets 1.1.x. In theory
there is a web config param to enable it:

javax.faces.DECORATORS

of in facelets 1.1.x

facelets.DECORATORS

Read JSF 2.1 spec section 11.1.3 related to javax.faces.DECORATORS:

"... A semicolon (;) delimitted list of class names of type
javax.faces.view.facelets.TagDecorator, with a no-argument
constructor. These decorators will be loaded when the first request
for a Facelets VDL view hits the ViewHandler for page compilation.The
runtime must also consider the facelets.DECORATORS param name as an
alias to this param name for backwards compatibility with existing
facelets tag libraries. ..."

The first thing you can see is the spec does not follow the convention
agreed to name parameters added from facelets. It should be named
javax.faces.FACELETS_DECORATORS and in MyFaces has that name, but now
is too late (I need to fix MyFaces). It seems some forgotten feature.

But the important part is what says in TagDecorator javadoc:

"... You could take <input type="text" /> and convert it to
<h:inputText /> before compiling. ..."

Sounds interesting. You can imagine someone just writing HTML pages
and use a TagDecorator to bind the gap, or do some logic here like
override component attributes to do something.

But anyway, it sounds more like something that was just a prototype
and to keep backwards compatibility with facelets it was included.

If is something to keep backward compatibility, why add a new param in
the spec of that? no reason at all?

I just wanted you guys to note this is a good place to override
facelets processing before compile the page. This is a good candidate
to include it in faces-config.xml inside facelet-extension element.
Maybe it could be useful to create a more compact syntax without
change facelets algorithm (imagine a x:input "virtual" tag, that with
some magic inside TagDecorator becomes h:inputText or j:email or
u:button). Or maybe there are better ways to do it
(TagHandlerDelegateFactory). Please keep it in mind, it could be
relevant ot the current discussion related to HTML5.

regards,

Leonardo Uribe