Re: Combining components
Cool!
looks good ;)
regards,
Martin
On 10/7/05, Udo Schnurpfeil <[EMAIL PROTECTED]> wrote:
> I've found a way to combine components to new tags.
>
> There was already some discussion on a similar topic:
> http://www.mail-archive.com/users@myfaces.apache.org/msg06438.html
> http://www.mail-archive.com/users@myfaces.apache.org/msg06369.html
>
> My first approach was to write a tag file (JSP 2.0) like
> (this is a non-working short-sample):
>
> file: inWithLabel.tag
>
> <%@ attribute name="label" %>
> <%@ attribute name="value" %>
> <%@ attribute name="binding" %>
>
>
>
>
>
>
> The first tests with "label" and "value" run well.
> But I found a big problem: If I want more advanced features like
> "binding" I have a problem: If the binding is not set the container will
> call setBinding("") with an empty string, which is not allowed.
>
> So I write the Tag by hand:
> int doStartTag() {
>PanelTag panel = new PanelTag();
>panel.setPageContext(pageContext);
>panel.doStartTag();
>...
> }
> You can see a real sample here:
> http://www.atanion.net/repos/asf/tobago/trunk/core/src/main/org/apache/myfaces/tobago/taglib/extension/InExtensionTag.java
>
> advantage of tag as java class:
>* Works with JSP 1.2
>* not need rtexpression (JSP EL) inside of JSF tags, which is in
> common not allowed.
>* setter only will be called, if the value != null
>
> advantage of tag file:
>* the tag file looks much more tidy
>
> Regards,
>
> Udo
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Combining components
I've found a way to combine components to new tags.
There was already some discussion on a similar topic:
http://www.mail-archive.com/users@myfaces.apache.org/msg06438.html
http://www.mail-archive.com/users@myfaces.apache.org/msg06369.html
My first approach was to write a tag file (JSP 2.0) like
(this is a non-working short-sample):
file: inWithLabel.tag
<%@ attribute name="label" %>
<%@ attribute name="value" %>
<%@ attribute name="binding" %>
The first tests with "label" and "value" run well.
But I found a big problem: If I want more advanced features like
"binding" I have a problem: If the binding is not set the container will
call setBinding("") with an empty string, which is not allowed.
So I write the Tag by hand:
int doStartTag() {
PanelTag panel = new PanelTag();
panel.setPageContext(pageContext);
panel.doStartTag();
...
}
You can see a real sample here:
http://www.atanion.net/repos/asf/tobago/trunk/core/src/main/org/apache/myfaces/tobago/taglib/extension/InExtensionTag.java
advantage of tag as java class:
* Works with JSP 1.2
* not need rtexpression (JSP EL) inside of JSF tags, which is in
common not allowed.
* setter only will be called, if the value != null
advantage of tag file:
* the tag file looks much more tidy
Regards,
Udo
Re: Combining components
On 1 Aug 2005, at 21:38, Mike Kienenberger wrote:
You can take a look at the thread entitied "composite controls" from 4
days ago for more alternatives and discussion.
Thx, willdo. (I was in vacation last week, and obviously missed the thread).
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.
value="#{myHandler.myPropertyLabel}" />
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 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:
xmlns:h="http://java.sun.com/jsf/html" >
required="true" />
type="java.lang.String "
required="true" />
value="#{handler[propertyName + 'Label']}" />
="#{handler[propertyName]}" />
and use it in the calling page as
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 Off
Re: Combining components
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:
xmlns:h="http://java.sun.com/jsf/html">
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 true for the value attribute.
We'll be trying this while we are developing a aliasBean2, that takes more than 1 binding. ;-).
regards,
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.
> >>
> >>
> >> value="#{myHandler.myPropertyLabel}" />
> >>
> >>
> >>
> >> 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 b
Re: Combining components
@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.
regards,
MartinOn 8/1/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
You can take a look at the thread entitied "composite controls" from 4days 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.> >>> >> > >> value="#{myHandler.myPropertyLabel}" />> >> > >> > >>> >> 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 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:> >>> >>
> >> http://java.sun.com/JSP/Page" version="2.0"> >> xmlns:h="http://java.sun.com/jsf/html
" >> >>> >> > >> required="true" />> >> > >> type="java.lang.String "> >> required="true" />> >>> >>
> >> value="#{handler[propertyName + 'Label']}" />> >> > >> ="#{handler[propertyName]}" />> >>
> >> > >>> >> and use it in the calling page as> >>> >>
> >>> >> 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 mes
Re: Combining components
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.
> >>
> >> >> value="#{myHandler.myPropertyLabel}" />
> >>
> >>
> >>
> >> 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 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:
> >>
> >>
> >> http://java.sun.com/JSP/Page"; version="2.0"
> >> xmlns:h="http://java.sun.com/jsf/html"; >
> >>
> >> >> required="true" />
> >> >> type="java.lang.String "
> >> required="true" />
> >>
> >> >> value="#{handler[propertyName + 'Label']}" />
> >> >> ="#{handler[propertyName]}" />
> >>
> >>
> >>
> >> and use it in the calling page as
> >>
> >>
> >>
> >> 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 Ja
Re: Combining components
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.
value="#{myHandler.myPropertyLabel}" />
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 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:
http://java.sun.com/JSP/Page" version="2.0"
xmlns:h="http://java.sun.com/jsf/html" >
required="true" />
required="true" />
value="#{handler[propertyName + 'Label']}" />
and use it in the calling page as
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.3
Re: Combining components
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...
If you want to do it JSP based (no real component architecture): 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)...
regards,
MartinOn 8/1/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
The question: what is the best practice to combine components in a new,encapsulated, parameterized entity?On of the features of component oriented development, in my view, isthat it is easy to define new components as combinations of existing
components. Take for instance the combination label, input field, anderror message.value="#{myHandler.myPropertyLabel}" />This occurs many times in any JSF application, and it is bad practiceto copy-paste this pattern all over your application. The pattern
should be encapsulated (I'm actually talking about more complexcombinations, but as an example, this will do). The encapsulationmechanism should allow for variation, of course. The easiest way ofvariation 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 programminglanguages. 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 codeto called code through request, session or application scope variables,the way original COBOL and FORTRAN allowed communication intosubroutines only via global variables (there was only 1 kind). With
ALGOL we finally got procedures that feature formal parameters. In JSP2, we finally thanked the gods for .tagx files: an easy way to combineexisting tags, that can be parameterized. Before .tagx files, we had to
write a new tag in Java code to get parameterization. Doable, buthardly as flexible.Now in JSF, we have the same problem. Again, we can include stuff(don't forget to use 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:
http://java.sun.com/JSP/Page" version="2.0" xmlns:h="http://java.sun.com/jsf/html"
> required="true" /> required="true" /> value="#{handler[propertyName + 'Label']}" />
and use it in the calling page as
The above sadly doesn't work. To start with, it wouldn't access themanaged bean facility.And if you take a look at the latest installment of JSF fornonbelievers(<
http://www-128.ibm.com/developerworks/java/library/j-jsf4/index.html?ca=drs->, final section), you see that Rich Hightower just rewrites allfunctionality of the output text, input text, and message tag in Java
for his combination tag. There is no reuse of the existing componentswhatsoever. Imaging doing this for all components (date, hidden,select, ...). As it turns out, we don't even see how we can reuseexisting components in Java code. That would be an acceptable stopgap.
So, the question: what is the best practice to combine components in anew, encapsulated, parameterized entity? Or is it simply not possible?Could we maybe emulate .tagx functionality with one JSF tag?
Met vriendelijke groeten,Jan DockxPeopleWare NV - Head OfficeCdt.Weynsstraat 85B-2660 HobokenTel: +32 3 448.33.38Fax: +32 3 448.32.66PeopleWare NV - Branch Office GeelKleinhoefstraat 5
B-2440 GeelTel: +32 14 57.00.90Fax: +32 14 58.13.25http://www.peopleware.be/http://www.mobileware.be/
Combining components
The question: what is the best practice to combine components in a new, 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. 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 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: xmlns:h="http://java.sun.com/jsf/html"> and use it in the calling page as 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 (, 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/ smime.p7s Description: S/MIME cryptographic signature
