You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Timo --Blazko-- Boewing <bl...@neveprise.net> on 2005/10/04 00:17:12 UTC
Tree2, event interception, criticism :-)
Hello all,
After having read almost every discussion here on the tree2 component, I
am having some final thoughts :-)
I am trying since two days now to get the 99,9% common case working:
having a tree component and intercepting centrally a clicked ID
belonging to the selected node.
First, I have no idea, why it takes quite much code to get this
component working, these f:facet stuff with manual h:commandLink etc. is
nice for customisation, but why not making this optional? I think most
people want to use the tree2 as it is in the examples. Everyone that
wants different style can write another renderer for this component, or
not? And most visual appearance can be achieved by using CSS and
exchanged images...
This would really cause much less coding in the frontend for users of
tree2 - I think it is way too much.
Now, in order to find out an ID of my node selected, I have to query an
f:param the "old" style? Why that? Additionally, in every example you
can read that "t.setNodeSelected" shall be used as action event
listener. Okay, what is "t"? It is never set up as a managed bean, and
only digging example sources and messages here lead up to an idea that
this might be an instance of HtmlTree or so whose instance I cannot
define myself. Okay, how to implement that action event fired, t being
hard wired? Or not? I think that much confusing stuff can be avoided
when documentating the common case in the component overview of the
website and the wiki. No one knows what node and varNodeToggler exactly
can do and how to intercept fired events.
Please, although between the lines that might sound that way, do not
feel offended! I am thankful for that wonderful stuff, especially
because it is an extra on top of JSF standard components.
However, please understand this as my way of constructive criticism that
may be well founded in my misunderstanding of something :-)
However, creating such a tree was very quickly done using tagfiles in
JSP 2.0, so I see less profit i using the tree2 component, that I would
like to use but causes much coding overhead in my POV.
--
greetings, | /"\
| \ / ASCII-Ribbon-Campaign
Timo | X Against HTML Mail
| / \
----------------------------------------------------------------------
PUBLIC KEY:
52F3311A Timo Boewing <bl...@neveprise.net> 2003/10/30
Fingerprint = F743 E0AA A2F0 1B33 F6FA 417B 72BE 740D 52F3 311A
Re: Tree2, event interception, criticism :-)
Posted by Sean Schofield <se...@gmail.com>.
I would disagree that the facets are overkill. They allow complete
control over the appearance of your tree without having to write a
renderer. I would argue that its much more burdensome for the average
user to write their own custom renderer then it is to use a facet.
In the initial design of tree2 I chose facets and other constructs
that JSF users should be well familiar with. So if you know how to
customize a table, you should be able to figure out how to customize
the tree. Writing your own renderer requires more detailed knowledge
of the component (not to mention access to the source, then chaning
faces-config.xml, etc.)
IMO its more important that you be able to handle 99% of the use cases
simply (ie. add another facet) then it is to have a few less lines of
code 99% of the time. Because when you want that extra flexability,
you won't care how many extra lines you add. Also, if your tree is
simple enough, you only need one facet and a couple of conditionally
rendered tags. It doesn't have to be as complex as some of the
examples shown. Those are the to illustrate the power you have in
controlling the appearance.
The 't' variable is a reference to the tree itself (technically the
"node toggler". Yes it is declared by the component. Just like the
var attribute is. Note, there is precedent for this in <h:dataTable>.
Its designed to give the JSP author access to component information
that might be useful. No big deal IMO.
No offense taken. You are welcome to make suggestions/criticisms as
long as they are not mean-spirited. I just happen to disagree with
most of your points.
sean
On 10/4/05, Martin Marinschek <ma...@gmail.com> wrote:
> Do you now that there is another tree-component available? the t:tree one?
>
> Maybe you want to give this one a try?
>
> And if you are not satisfied with either, you can always try to extend
> those two, and send us any changes you implement when working on them.
>
> regards,
>
> Martin
>
> On 10/4/05, Marcel Ruff <mr...@marcelruff.info> wrote:
> > Timo --Blazko-- Boewing wrote:
> >
> > >Hello all,
> > >
> > >After having read almost every discussion here on the tree2 component, I
> > >am having some final thoughts :-)
> > >I am trying since two days now to get the 99,9% common case working:
> > >having a tree component and intercepting centrally a clicked ID
> > >belonging to the selected node.
> > >
> > >First, I have no idea, why it takes quite much code to get this
> > >component working, these f:facet stuff with manual h:commandLink etc. is
> > >nice for customisation, but why not making this optional? I think most
> > >people want to use the tree2 as it is in the examples. Everyone that
> > >wants different style can write another renderer for this component, or
> > >not? And most visual appearance can be achieved by using CSS and
> > >exchanged images...
> > >This would really cause much less coding in the frontend for users of
> > >tree2 - I think it is way too much.
> > >
> > >Now, in order to find out an ID of my node selected, I have to query an
> > >f:param the "old" style? Why that? Additionally, in every example you
> > >can read that "t.setNodeSelected" shall be used as action event
> > >listener. Okay, what is "t"? It is never set up as a managed bean, and
> > >only digging example sources and messages here lead up to an idea that
> > >this might be an instance of HtmlTree or so whose instance I cannot
> > >define myself. Okay, how to implement that action event fired, t being
> > >hard wired? Or not? I think that much confusing stuff can be avoided
> > >when documentating the common case in the component overview of the
> > >website and the wiki. No one knows what node and varNodeToggler exactly
> > >can do and how to intercept fired events.
> > >
> > >Please, although between the lines that might sound that way, do not
> > >feel offended! I am thankful for that wonderful stuff, especially
> > >because it is an extra on top of JSF standard components.
> > >However, please understand this as my way of constructive criticism that
> > >may be well founded in my misunderstanding of something :-)
> > >However, creating such a tree was very quickly done using tagfiles in
> > >JSP 2.0, so I see less profit i using the tree2 component, that I would
> > >like to use but causes much coding overhead in my POV.
> > >
> > >
> > >
> > + my 10 Cents, you express exactly my feelings.
> >
> > Marcel
> >
> > PS: What is POV? (for me it is POB = plain old brain)
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>
Re: Tree2, event interception, criticism :-)
Posted by Timo --Blazko-- Boewing <bl...@neveprise.net>.
Hello Martin,
On Tue, 2005-10-04 at 10:51 +0200, Martin Marinschek wrote:
> Do you now that there is another tree-component available? the t:tree one?
Yepp, but when I stumbled over the Wiki, I found this note:
"Tree renders data in the form of a tree, using a <table> in the
rendered HTML. This component is more or less considered obsolete. Take
a look at tree2 instead."
Okay, it is working but sounds to me that it might someday just
disappeas as long as I do not maintain it myself or someone other.
>
> Maybe you want to give this one a try?
>
> And if you are not satisfied with either, you can always try to extend
> those two, and send us any changes you implement when working on them.
I really would like to, but I must say that I am sometimes really afraid
of these SVN stuff, I might break other's valuable work due to my
stupidity :-)
The problem is that I am still learning JSF and I think doing something
that I am not shure of is worse than doing nothing. Not that I am that
bad in coding, but I just have to get more knowledge on JSF before I
might add my 2 cents to something.
Marcel: POV: point of view, but your brainer was also a nice thing :-)
>
> regards,
>
> Martin
>
Thanks for the hint and kind regards,
--
greetings, | /"\
| \ / ASCII-Ribbon-Campaign
Timo | X Against HTML Mail
| / \
Re: Tree2, event interception, criticism :-)
Posted by Martin Marinschek <ma...@gmail.com>.
Do you now that there is another tree-component available? the t:tree one?
Maybe you want to give this one a try?
And if you are not satisfied with either, you can always try to extend
those two, and send us any changes you implement when working on them.
regards,
Martin
On 10/4/05, Marcel Ruff <mr...@marcelruff.info> wrote:
> Timo --Blazko-- Boewing wrote:
>
> >Hello all,
> >
> >After having read almost every discussion here on the tree2 component, I
> >am having some final thoughts :-)
> >I am trying since two days now to get the 99,9% common case working:
> >having a tree component and intercepting centrally a clicked ID
> >belonging to the selected node.
> >
> >First, I have no idea, why it takes quite much code to get this
> >component working, these f:facet stuff with manual h:commandLink etc. is
> >nice for customisation, but why not making this optional? I think most
> >people want to use the tree2 as it is in the examples. Everyone that
> >wants different style can write another renderer for this component, or
> >not? And most visual appearance can be achieved by using CSS and
> >exchanged images...
> >This would really cause much less coding in the frontend for users of
> >tree2 - I think it is way too much.
> >
> >Now, in order to find out an ID of my node selected, I have to query an
> >f:param the "old" style? Why that? Additionally, in every example you
> >can read that "t.setNodeSelected" shall be used as action event
> >listener. Okay, what is "t"? It is never set up as a managed bean, and
> >only digging example sources and messages here lead up to an idea that
> >this might be an instance of HtmlTree or so whose instance I cannot
> >define myself. Okay, how to implement that action event fired, t being
> >hard wired? Or not? I think that much confusing stuff can be avoided
> >when documentating the common case in the component overview of the
> >website and the wiki. No one knows what node and varNodeToggler exactly
> >can do and how to intercept fired events.
> >
> >Please, although between the lines that might sound that way, do not
> >feel offended! I am thankful for that wonderful stuff, especially
> >because it is an extra on top of JSF standard components.
> >However, please understand this as my way of constructive criticism that
> >may be well founded in my misunderstanding of something :-)
> >However, creating such a tree was very quickly done using tagfiles in
> >JSP 2.0, so I see less profit i using the tree2 component, that I would
> >like to use but causes much coding overhead in my POV.
> >
> >
> >
> + my 10 Cents, you express exactly my feelings.
>
> Marcel
>
> PS: What is POV? (for me it is POB = plain old brain)
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: Tree2, event interception, criticism :-)
Posted by Marcel Ruff <mr...@marcelruff.info>.
Timo --Blazko-- Boewing wrote:
>Hello all,
>
>After having read almost every discussion here on the tree2 component, I
>am having some final thoughts :-)
>I am trying since two days now to get the 99,9% common case working:
>having a tree component and intercepting centrally a clicked ID
>belonging to the selected node.
>
>First, I have no idea, why it takes quite much code to get this
>component working, these f:facet stuff with manual h:commandLink etc. is
>nice for customisation, but why not making this optional? I think most
>people want to use the tree2 as it is in the examples. Everyone that
>wants different style can write another renderer for this component, or
>not? And most visual appearance can be achieved by using CSS and
>exchanged images...
>This would really cause much less coding in the frontend for users of
>tree2 - I think it is way too much.
>
>Now, in order to find out an ID of my node selected, I have to query an
>f:param the "old" style? Why that? Additionally, in every example you
>can read that "t.setNodeSelected" shall be used as action event
>listener. Okay, what is "t"? It is never set up as a managed bean, and
>only digging example sources and messages here lead up to an idea that
>this might be an instance of HtmlTree or so whose instance I cannot
>define myself. Okay, how to implement that action event fired, t being
>hard wired? Or not? I think that much confusing stuff can be avoided
>when documentating the common case in the component overview of the
>website and the wiki. No one knows what node and varNodeToggler exactly
>can do and how to intercept fired events.
>
>Please, although between the lines that might sound that way, do not
>feel offended! I am thankful for that wonderful stuff, especially
>because it is an extra on top of JSF standard components.
>However, please understand this as my way of constructive criticism that
>may be well founded in my misunderstanding of something :-)
>However, creating such a tree was very quickly done using tagfiles in
>JSP 2.0, so I see less profit i using the tree2 component, that I would
>like to use but causes much coding overhead in my POV.
>
>
>
+ my 10 Cents, you express exactly my feelings.
Marcel
PS: What is POV? (for me it is POB = plain old brain)