On 1 Aug 2005, at 21:54, Martin Marinschek wrote:
@aliasBean: yes, you can just pile them up to get more than one parameter
JSF 1.2 will - afaik - not include anything to use .tagx files in JSF.
the hard thing is that the components need not only be composed for the rendering phase, but also for the decode phase and everything in between.
I don't buy that. There is no need to "compose components" actually. As you undoubtedly know, the only function of the JSP tags in JSF is to create components in the UIView tree. The only thing we need to "combine components" for the developer is a JSP tag that creates more than 1 component in the UIView tree, which can simply be done by creating an include file, or a tagx file, that lists the tags that will create the separate components in the UIView tree. We need to compose tags, not components. The components will operate uncomposed in the UIView tree.
The only problem we have is with the argument passing. This could, BTW, be solved quite quickly (maybe not nicely, but quickly), by allowing JSP EL for JSF tag attributes. Then the tag in my example would look like:
<?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="handlerJsfElExpression" type="java.lang.String" required="true" />
<jsp:directive.attribute name="propertyName" type="java.lang.String" required="true" />
<x:aliasBean var="handler" value="${handlerJsfElExpression}" />
<h:outputText id="#{propertyName}_label" value="#{handler[propertyName + 'Label']}" />
<h:inputText id="#{propertyName}" value ="#{handler[propertyName]}" />
<h:message id="#{propertyName}_messages" for="#{propertyName}" />
</x:aliasBean>
</jsp:root>
.... wait a sec ...
Actually, that doesn't look half as idiotic as I thought it would. As far as I can see now, this only requires a change in the TLD for x:aliasBean.
Set the entry <rtexprvalue>true</rtexprvalue> for the value attribute.
We'll be trying this while we are developing a aliasBean2, that takes more than 1 binding. ;-).
regards,<x-tad-smaller>Met vriendelijke groeten,
Martin
On 8/1/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
days ago for more alternatives and discussion.
On 8/1/05, ir. ing. Jan Dockx <[EMAIL PROTECTED] > wrote:
>
> 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,
> >
> > 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, wefinally 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/
> >>
> >
> >
> 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
