On of the features of component oriented development, in my view, is that it is easy to define new components as combinations of existing components. Take for instance the combination label, input field, and error message.
<h:outputText id="myProperty_label" value="#{myHandler.myPropertyLabel}" />
<h:inputText id="myProperty" value ="#{myHandler.myProperty}" />
<h:message id="myProperty_messages" for="myProperty" />
This occurs many times in any JSF application, and it is bad practice to copy-paste this pattern all over your application. The pattern should be encapsulated (I'm actually talking about more complex combinations, but as an example, this will do). The encapsulation mechanism should allow for variation, of course. The easiest way of variation is parameterization. In the example, we want the handler and the property name to be parameterized.
We have been this way with JSP, following the history of programming languages. Static includes gives us the possibility to reuse code (macro languages). Dynamic includes give more flexibility, but parameterization is not supported. We can communicate from calling code to called code through request, session or application scope variables, the way original COBOL and FORTRAN allowed communication into subroutines only via global variables (there was only 1 kind). With ALGOL we finally got procedures that feature formal parameters. In JSP 2, we finally thanked the gods for .tagx files: an easy way to combine existing tags, that can be parameterized. Before .tagx files, we had to write a new tag in Java code to get parameterization. Doable, but hardly as flexible.
Now in JSF, we have the same problem. Again, we can include stuff (don't forget to use <subview /> though), but this is not parameterizable. And we don't see a way to use .tagx files with JSF, since we cannot mix JSP EL with JSF EL.
We would want to write the following myTag.tagx file:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
xmlns:h="http://java.sun.com/jsf/html">
<jsp:directive.attribute name="handler" type="java.lang.Object" required="true" />
<jsp:directive.attribute name="propertyName" type="java.lang.String" required="true" />
<h:outputText id="${propertyName}_label" value="#{handler[propertyName + 'Label']}" />
<h:inputText id="${propertyName}" value ="#{handler[propertyName]}" />
<h:message id="${propertyName}_messages" for="${propertyName}" />
</jsp:root>
and use it in the calling page as
<q:myTag handler="#{myHandler}" propertyName="myProperty" />
The above sadly doesn't work. To start with, it wouldn't access the managed bean facility.
And if you take a look at the latest installment of JSF for nonbelievers (<http://www-128.ibm.com/developerworks/java/library/j-jsf4/index.html?ca=drs->, final section), you see that Rich Hightower just rewrites all functionality of the output text, input text, and message tag in Java for his combination tag. There is no reuse of the existing components whatsoever. Imaging doing this for all components (date, hidden, select, ...). As it turns out, we don't even see how we can reuse existing components in Java code. That would be an acceptable stopgap.
So, the question: what is the best practice to combine components in a new, encapsulated, parameterized entity? Or is it simply not possible? Could we maybe emulate .tagx functionality with one JSF tag?
<x-tad-smaller>Met vriendelijke groeten,
Jan Dockx
</x-tad-smaller><x-tad-smaller>
PeopleWare NV - Head Office</x-tad-smaller><x-tad-smaller>
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66 </x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
PeopleWare NV - Branch Office Geel</x-tad-smaller><x-tad-smaller>
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25</x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
http://www.peopleware.be/
</x-tad-smaller><x-tad-smaller>http://www.mobileware.be/</x-tad-smaller>
smime.p7s
Description: S/MIME cryptographic signature
