You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Tim Pyle <tp...@portiva.com> on 2005/03/18 17:14:30 UTC
Tree2 Problem
Well Sean I finally found my problem with reading from the wrong
myfaces.jar. It was actually picking up it from the
myfaces-examples.war. So now I have that working with the new code, and
sure enough, the warnings are all gone. I am now getting this error when
rebuilding the tree based on a filter.
[Engine] StandardContext[/jport]Node with id 0:2:21. Failed to parse
0:2:21
[exec] java.lang.IllegalArgumentException: Node with id 0:2:21.
Failed to parse 0:2:21
I have found that this only occurs when cookies are enabled on the
browser. If I disable the cookies, then the tree rebuilds with the new
data without error. Is there a way to tell the tree not to try and save
state via a cookie. Seems like maybe a simple attribute addition to the
TreeTag... maybe useCookie="false" type of thing.
Tim Pyle
Re: Tree2 Problem
Posted by Sean Schofield <se...@gmail.com>.
> I don't think issuing a warning is the correct way to go. Since in the
> case that somebody needs this behaviour he is always bombarded by
> warnings from his tree. This will clog up his logs and can be very
> annoying. (Had a similar problem with an old version of datatable : ( )
> What I would suggest is that the tree simply ignores the fact that it
> can't find certain nodes or even better make it that the user can turn
> this behaviour on or off.
> IMHO a warning is an error.
The warning would be in addition to the option to not save the
expanded state info. So if Time were to use that option, he would
never get a warning. So the option to ignore the expanded state info
will solve his problem 100% without any warnings.
I was addressing a second issue that might come up. Suppose two users
are looking at the same tree. Suppose the first user does something
to cause the node to disappear in the database. Now suppose user 2
clicks on that node. What do we do now? I think the answer depends
on the situation. Are you just trying to record the user clicked on
that node or are you trying to load a resource or do something in an
action based on that click?
Its a complicated problem (although not one that is likely to come up
often.) I don't think you can just ignore it as you are suggesting.
IMO a warning is appropriate if you decide to do nothing but we may
still need to throw an exception in situations where we can't continue
without a node.
> Stefan
sean
Re: Tree2 Problem
Posted by Stefan Langer <my...@bettsockentraeger.de>.
Sean Schofield wrote:
>OK well that explains the problem. I have two ideas to improve tree2
>on this front:
>
>
>2.) Generate a warning (instead of exception) if the node cannot be
>found. This way if you do want to preserve node state but you have
>the unusual case where the underlying data changes, you don't crash.
>Obviously in your case it won't be unusual but there are other cases
>where perhaps another user updated the database in between posts and
>so the underlying tree data changed. Maybe also a preserveTreeModel
>attribute similar to preserveDataModel for <x:dataTable> ...
>
>I will work on a patch for #1 and think about #2
>
>sean
>
>
Hello Sean,
I don't think issuing a warning is the correct way to go. Since in the
case that somebody needs this behaviour he is always bombarded by
warnings from his tree. This will clog up his logs and can be very
annoying. (Had a similar problem with an old version of datatable : ( )
What I would suggest is that the tree simply ignores the fact that it
can't find certain nodes or even better make it that the user can turn
this behaviour on or off.
IMHO a warning is an error.
just my 2ct.
Regards
Stefan
Re: Tree2 Problem
Posted by Sean Schofield <se...@gmail.com>.
OK well that explains the problem. I have two ideas to improve tree2
on this front:
1.) Have the option to not maintain the expand/collapse state info.
Basically a saveExpandedState attribute (true|false) with a default of
true. This will fix your problem.
2.) Generate a warning (instead of exception) if the node cannot be
found. This way if you do want to preserve node state but you have
the unusual case where the underlying data changes, you don't crash.
Obviously in your case it won't be unusual but there are other cases
where perhaps another user updated the database in between posts and
so the underlying tree data changed. Maybe also a preserveTreeModel
attribute similar to preserveDataModel for <x:dataTable> ...
I will work on a patch for #1 and think about #2
sean
On Mon, 21 Mar 2005 09:22:44 -0600, Tim Pyle <tp...@portiva.com> wrote:
> On this particular page, I am only using the one tree. On this same
> page, I have a drop down, with different file extensions. When the tree
> first comes up initially, it is unfiltered(it has all files). The drop
> down has the attribute onclick=submit() on it. So when they choose a
> particular extension, the page is submitted and the tree gets rebuilt
> with only the files that have the chosen extension. So this is whee the
> problem is... you are correct, the tree is trying to rebuild nodes that
> no longer exist. In this example, I do not need the tree to save it's
> state, I need it to be rebuilt from the top down, so this is why I was
> suggesting maybe an attribute so the user can control this behavior. I
> am sure it will not be used too often, but who knows.
>
> Tim Pyle
>
> On Sun, 2005-03-20 at 09:21, Sean Schofield wrote:
> > Well the cookies are used during client-side toggle. They are session
> > only cookies (they go away when the browser window is closed.) Right
> > now they are the mechnasism for posting back any changes to the
> > expand/collapse state you made via javascript before clicking on a
> > tree node.
> >
> > There are other possible mechanisms for doing this besides cookies. I
> > am not entirely satisified with the cookie approach but it gets pretty
> > complicated using something other than cookies. I'd be interested if
> > anyone out there has some ideas on this. I'd especially like to see
> > some code (or a patch) that actually works. I've run into a few
> > issues when it gets down to actually making it work.
> >
> > My guess is that you are posting cookie information pertaining to an
> > old tree? Is that possible? The error message seems to indicate that
> > there is no such node 0:2:21. Btw that notation would mean first
> > branch, then the third branch under that, then the 22nd leaf.
> >
> > Its possible that the cookie information is not being maintained
> > separately for your two trees. (You're using two trees right?) If
> > this is the case, it could be trying to apply the one set of state
> > information to the other tree. Try removing the one tree temporarily
> > and see if you still have the problem. I will look into if this is an
> > issue.
> >
> > Finally, when you say it works fine without cookies enabled, I'm
> > assuming you are not saying that the expand/collapse state information
> > works fine. I would think that you would lose information on any
> > nodes that had a change in this state on the client before you posted.
> >
> > Regards,
> > sean
> >
> >
> > On Fri, 18 Mar 2005 10:14:30 -0600, Tim Pyle <tp...@portiva.com> wrote:
> > > Well Sean I finally found my problem with reading from the wrong
> > > myfaces.jar. It was actually picking up it from the
> > > myfaces-examples.war. So now I have that working with the new code, and
> > > sure enough, the warnings are all gone. I am now getting this error when
> > > rebuilding the tree based on a filter.
> > >
> > > [Engine] StandardContext[/jport]Node with id 0:2:21. Failed to parse
> > > 0:2:21
> > > [exec] java.lang.IllegalArgumentException: Node with id 0:2:21.
> > > Failed to parse 0:2:21
> > >
> > > I have found that this only occurs when cookies are enabled on the
> > > browser. If I disable the cookies, then the tree rebuilds with the new
> > > data without error. Is there a way to tell the tree not to try and save
> > > state via a cookie. Seems like maybe a simple attribute addition to the
> > > TreeTag... maybe useCookie="false" type of thing.
> > >
> > > Tim Pyle
> > >
> > >
>
>
Re: Tree2 Problem
Posted by Tim Pyle <tp...@portiva.com>.
On this particular page, I am only using the one tree. On this same
page, I have a drop down, with different file extensions. When the tree
first comes up initially, it is unfiltered(it has all files). The drop
down has the attribute onclick=submit() on it. So when they choose a
particular extension, the page is submitted and the tree gets rebuilt
with only the files that have the chosen extension. So this is whee the
problem is... you are correct, the tree is trying to rebuild nodes that
no longer exist. In this example, I do not need the tree to save it's
state, I need it to be rebuilt from the top down, so this is why I was
suggesting maybe an attribute so the user can control this behavior. I
am sure it will not be used too often, but who knows.
Tim Pyle
On Sun, 2005-03-20 at 09:21, Sean Schofield wrote:
> Well the cookies are used during client-side toggle. They are session
> only cookies (they go away when the browser window is closed.) Right
> now they are the mechnasism for posting back any changes to the
> expand/collapse state you made via javascript before clicking on a
> tree node.
>
> There are other possible mechanisms for doing this besides cookies. I
> am not entirely satisified with the cookie approach but it gets pretty
> complicated using something other than cookies. I'd be interested if
> anyone out there has some ideas on this. I'd especially like to see
> some code (or a patch) that actually works. I've run into a few
> issues when it gets down to actually making it work.
>
> My guess is that you are posting cookie information pertaining to an
> old tree? Is that possible? The error message seems to indicate that
> there is no such node 0:2:21. Btw that notation would mean first
> branch, then the third branch under that, then the 22nd leaf.
>
> Its possible that the cookie information is not being maintained
> separately for your two trees. (You're using two trees right?) If
> this is the case, it could be trying to apply the one set of state
> information to the other tree. Try removing the one tree temporarily
> and see if you still have the problem. I will look into if this is an
> issue.
>
> Finally, when you say it works fine without cookies enabled, I'm
> assuming you are not saying that the expand/collapse state information
> works fine. I would think that you would lose information on any
> nodes that had a change in this state on the client before you posted.
>
> Regards,
> sean
>
>
> On Fri, 18 Mar 2005 10:14:30 -0600, Tim Pyle <tp...@portiva.com> wrote:
> > Well Sean I finally found my problem with reading from the wrong
> > myfaces.jar. It was actually picking up it from the
> > myfaces-examples.war. So now I have that working with the new code, and
> > sure enough, the warnings are all gone. I am now getting this error when
> > rebuilding the tree based on a filter.
> >
> > [Engine] StandardContext[/jport]Node with id 0:2:21. Failed to parse
> > 0:2:21
> > [exec] java.lang.IllegalArgumentException: Node with id 0:2:21.
> > Failed to parse 0:2:21
> >
> > I have found that this only occurs when cookies are enabled on the
> > browser. If I disable the cookies, then the tree rebuilds with the new
> > data without error. Is there a way to tell the tree not to try and save
> > state via a cookie. Seems like maybe a simple attribute addition to the
> > TreeTag... maybe useCookie="false" type of thing.
> >
> > Tim Pyle
> >
> >
Re: Tree2 Problem
Posted by Sean Schofield <se...@gmail.com>.
Just a follow up to my earlier post. I checked a two tree example on
my own and I did not have any problems. I also verified that each
tree is maintaining its own cookie so that is not the source of the
problem.
The most likely cause is that the tree data is changing in between
posts. Is that pssible in your situation? I can work on a solution
to handle things if the node is no longer available but I would like
to understand more before I contemplate this.
sean
On Sun, 20 Mar 2005 10:21:56 -0500, Sean Schofield
<se...@gmail.com> wrote:
> Well the cookies are used during client-side toggle. They are session
> only cookies (they go away when the browser window is closed.) Right
> now they are the mechnasism for posting back any changes to the
> expand/collapse state you made via javascript before clicking on a
> tree node.
>
> There are other possible mechanisms for doing this besides cookies. I
> am not entirely satisified with the cookie approach but it gets pretty
> complicated using something other than cookies. I'd be interested if
> anyone out there has some ideas on this. I'd especially like to see
> some code (or a patch) that actually works. I've run into a few
> issues when it gets down to actually making it work.
>
> My guess is that you are posting cookie information pertaining to an
> old tree? Is that possible? The error message seems to indicate that
> there is no such node 0:2:21. Btw that notation would mean first
> branch, then the third branch under that, then the 22nd leaf.
>
> Its possible that the cookie information is not being maintained
> separately for your two trees. (You're using two trees right?) If
> this is the case, it could be trying to apply the one set of state
> information to the other tree. Try removing the one tree temporarily
> and see if you still have the problem. I will look into if this is an
> issue.
>
> Finally, when you say it works fine without cookies enabled, I'm
> assuming you are not saying that the expand/collapse state information
> works fine. I would think that you would lose information on any
> nodes that had a change in this state on the client before you posted.
>
> Regards,
> sean
>
>
> On Fri, 18 Mar 2005 10:14:30 -0600, Tim Pyle <tp...@portiva.com> wrote:
> > Well Sean I finally found my problem with reading from the wrong
> > myfaces.jar. It was actually picking up it from the
> > myfaces-examples.war. So now I have that working with the new code, and
> > sure enough, the warnings are all gone. I am now getting this error when
> > rebuilding the tree based on a filter.
> >
> > [Engine] StandardContext[/jport]Node with id 0:2:21. Failed to parse
> > 0:2:21
> > [exec] java.lang.IllegalArgumentException: Node with id 0:2:21.
> > Failed to parse 0:2:21
> >
> > I have found that this only occurs when cookies are enabled on the
> > browser. If I disable the cookies, then the tree rebuilds with the new
> > data without error. Is there a way to tell the tree not to try and save
> > state via a cookie. Seems like maybe a simple attribute addition to the
> > TreeTag... maybe useCookie="false" type of thing.
> >
> > Tim Pyle
> >
> >
>
Re: Tree2 Problem
Posted by Sean Schofield <se...@gmail.com>.
Well the cookies are used during client-side toggle. They are session
only cookies (they go away when the browser window is closed.) Right
now they are the mechnasism for posting back any changes to the
expand/collapse state you made via javascript before clicking on a
tree node.
There are other possible mechanisms for doing this besides cookies. I
am not entirely satisified with the cookie approach but it gets pretty
complicated using something other than cookies. I'd be interested if
anyone out there has some ideas on this. I'd especially like to see
some code (or a patch) that actually works. I've run into a few
issues when it gets down to actually making it work.
My guess is that you are posting cookie information pertaining to an
old tree? Is that possible? The error message seems to indicate that
there is no such node 0:2:21. Btw that notation would mean first
branch, then the third branch under that, then the 22nd leaf.
Its possible that the cookie information is not being maintained
separately for your two trees. (You're using two trees right?) If
this is the case, it could be trying to apply the one set of state
information to the other tree. Try removing the one tree temporarily
and see if you still have the problem. I will look into if this is an
issue.
Finally, when you say it works fine without cookies enabled, I'm
assuming you are not saying that the expand/collapse state information
works fine. I would think that you would lose information on any
nodes that had a change in this state on the client before you posted.
Regards,
sean
On Fri, 18 Mar 2005 10:14:30 -0600, Tim Pyle <tp...@portiva.com> wrote:
> Well Sean I finally found my problem with reading from the wrong
> myfaces.jar. It was actually picking up it from the
> myfaces-examples.war. So now I have that working with the new code, and
> sure enough, the warnings are all gone. I am now getting this error when
> rebuilding the tree based on a filter.
>
> [Engine] StandardContext[/jport]Node with id 0:2:21. Failed to parse
> 0:2:21
> [exec] java.lang.IllegalArgumentException: Node with id 0:2:21.
> Failed to parse 0:2:21
>
> I have found that this only occurs when cookies are enabled on the
> browser. If I disable the cookies, then the tree rebuilds with the new
> data without error. Is there a way to tell the tree not to try and save
> state via a cookie. Seems like maybe a simple attribute addition to the
> TreeTag... maybe useCookie="false" type of thing.
>
> Tim Pyle
>
>