Tag files for rendering JSF components

Question

Hi people!
     It is possible to render component JSF using Tag-Files? (WEB-INF/tags).
I am having problems with context, seems that the JSF does not recognize pageContext.
Ex:
My Tag-File
<%@ attribute name="nameproperty" required="true" rtexprvalue="true" %>
<%@ attribute name="size"           required="true" rtexprvalue="true" %>
<h:inputText id="${nameproperty}"      size="#{size}" />
My JSP
<%@ taglib tagdir="/WEB-INF/tags" prefix="mayTags"%>
<f:subview id="id001" >
     <myTags:myText propriedade="name_test" size="30" />
</f:subview>
In this in case that the size always is empty, because it does not recognize the target pageContext, but if I to place the size in the target of request already recognizes.
EX:
<%@ attribute name="nameproperty"      required="true" rtexprvalue="true" %>
<%@ attribute name="size"           required="true" rtexprvalue="true" %>
<c:set var"size" value="${size}" scope="request" >
<h:inputText id="${nameproperty}"      size="#{size}" />
In part it decides my problem, but it causes another error, is that if in my JSP it will have two fields (this is more than common) calling tag-file, there the size placed in request is always of it I finish field.
Ex:
<%@ taglib tagdir="/WEB-INF/tags" prefix="mayTags"%>
<f:subview id="paisMan" >
     <myTags:myText propriedade="name_test" size="30" />
     <myTags:myText propriedade="name_test_2" size="70" />
</f:subview>
In this case all the two inputText would have size 70.
It has some thing that I can make to solve this problem?
Thanks for any help.
Pedro Neves - Brazil

Answer 1

You are right in saying that decoding has nothing to
do with rendering per se.I will go even further than Erik did, and dispute this statement.
Consider that you are generating an <input> tag for a text field. Among other things, you have to generate a "name" attribute. Who decides what to put there? The renderer that actually created the markup.
The "renderer" really does
two completely different things. But both should
nevertheless be separate from the component
implementation itself. You could still have the
renderer doing the decoding part, which arguably would
rarely change, and somehow delegate the actual
rendering to an implementation in a tag file.Whether you implement decoding in a separate class or inside the component, what request parameter name do you look for? It is not reasonable to assume that ALL possible renderers will choose the same parameter name ... hence, decoding and encoding are inextricably linked (the code doing the decoding has to know what kind of markup the code doing the encoding actually created). In JavaServer Faces, the current APIs create that linkage by requiring that the decode and encode be done by the same class (either the component, if you are not delegating, or the renderer if you are).
Craig