myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <sean.schofi...@gmail.com>
Subject Re: Tree2 Problem
Date Mon, 21 Mar 2005 16:47:05 GMT
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 <tpyle@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 <tpyle@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
> > >
> > >
> 
>

Mime
View raw message