You can take a look at the thread entitied "composite controls" from 4
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/
>
>
>
