On 1 Aug 2005, at 12:14, Martin Marinschek wrote:
You do that by simply instantiating components in your Renderer.encodeEnd method, set the appropriate attributes and call encodEnd on this components.
See HtmlInputCalendar as an example, or other custom components in MyFaces...
We'll have a look. We expect it to be a little more complicated than that, though, but we will get back on that.
Anyway, it still would be a lot complexer than creating a tagx, though.
If you want to do it JSP based (no real component architecture):
Let's not get into that one ;-). For several years, the semantics of the word "component", "component based programming", etc., was the main topic of OOPSLA and ECOOP papers and workshops. As Dijkstra said about the topic in 1968, there should be a Journal of Half-baked Ideas … ;-).
use alias beans (x:aliasBean) and jsp:include tags together (you cannot use the standard param technology of jsp:include and/or tiles, as JSF won't be able to resolve those params correctly for example in the decode phase)...
Well, yes, indeed. The aliasBean works much like global variables for original FORTRAN and COBOL, although a bit better. And I suppose we should nest several aliasBean tags if we want to convey more than 1 parameter?
This is no more than a stopgap. We'll use it for now, but we're akin for something better.
So, does anybody know whether JSF 1.2 will make the use of tagx files possible? And does anybody have inside information on how 1.2 is proceeding? (We know some have, but are they free to say? ;-) ).
regards,<x-tad-smaller>Met vriendelijke groeten,
Martin
On 8/1/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
encapsulated, parameterized entity?
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?
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
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
