You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by "ir. ing. Jan Dockx" <ja...@mac.com> on 2005/08/01 11:50:34 UTC
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.
<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/
Re: Combining components
Posted by Martin Marinschek <ma...@gmail.com>.
Cool!
looks good ;)
regards,
Martin
On 10/7/05, Udo Schnurpfeil <ud...@atanion.com> 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" %>
>
> <t:panel>
> <t:label value="${label}">
> <t:in value="${value}" binding="${binding}">
> </t:panel>
>
> 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
Posted by Udo Schnurpfeil <ud...@atanion.com>.
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" %>
<t:panel>
<t:label value="${label}">
<t:in value="${value}" binding="${binding}">
</t:panel>
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
Posted by "ir. ing. Jan Dockx" <ja...@mac.com>.
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,
>
> Martin
>
> On 8/1/05, Mike Kienenberger <mk...@gmail.com> wrote:
>> days ago for more alternatives and discussion.
>>
>> On 8/1/05, ir. ing. Jan Dockx <jandockx@mac.com > 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 <ja...@mac.com> 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/
>> >
>> >
>> >
>>
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/
Re: Combining components
Posted by Martin Marinschek <ma...@gmail.com>.
@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,
Martin
On 8/1/05, Mike Kienenberger <mk...@gmail.com> wrote:
>
> 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 <ja...@mac.com> 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 <ja...@mac.com> 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/
> >
> >
> >
>
Re: Combining components
Posted by "ir. ing. Jan Dockx" <ja...@mac.com>.
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 <ja...@mac.com> 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 <ja...@mac.com> 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/
>>
>>
>>
>>
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/
Re: Combining components
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <ja...@mac.com> 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 <ja...@mac.com> 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/
>
>
>
Re: Combining components
Posted by "ir.ing.Jan Dockx" <ja...@mac.com>.
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 <ja...@mac.com> 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/
>>
>
>
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/
Re: Combining components
Posted by Martin Marinschek <ma...@gmail.com>.
You do that by simply instantiating components in your
Renderer.encodeEndmethod, 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,
Martin
On 8/1/05, ir. ing. Jan Dockx <ja...@mac.com> 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, 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/
>
>