You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Vjeran Marcinko <vj...@tis.hr> on 2004/04/16 09:21:53 UTC
[BUG?] ITreeNode's hashCode() and equals()
Hi again.
I'm flooding this mailing list with my contrib:Tree posts :-)
It seems that something's wrong with contrib:Tree the way it identifies
expanded nodes. Warner Ostine posted about this same problem few weeks ago.
Anyway, I created my own implementation of ITreeNode and root node doesn't
get expanded, same as Warner experienced. I was doing some digging and
problem is that when root node is expanded it is stored in
SimpleTreeStateModel inside internal HashSet as some TreePath object, but
when tree gets rendered it instantiates new TreePath for same root node and
tries to find out if this node is expanded by searching this HashSet. And
normally, it doesn't find it so it renders this root node closed, thus root
node can never expand.
In all the working examples that I've seen, ITreeNode's implementations
(FileSystem, TestTreeNode, Warner's solution) gets around this problem by
overriding equals() and hashCode() methods with node's name comparison.
Although this would probably be sufficient for most cases, I think that
differentiation between node objects should not be on the basis of their
names. In fact, I'm sure it is not suposed to be that way, since when
someone implements his own ITreeNode, he expects it will work, but it
doesn't as long as he doesn't override equals() and hashCode() with name
comparison inside.
-Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: [BUG?] ITreeNode's hashCode() and equals()
Posted by Vjeran Marcinko <vj...@tis.hr>.
----- Original Message -----
From: "tsvetelin" <ts...@rushmore-digital.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, April 16, 2004 2:04 PM
Subject: RE: [BUG?] ITreeNode's hashCode() and equals()
> To solve this problem you can choose from the following approaches:
> 2. You should create your tree data structure only one time in the
> application, if this is possible. For example, if have hard coded number
of
> nodes. In that case the default equals works fine.
Hmmm... I placed my ITreeModel implementation in Visit object, thus it is
instantiated only once along with it's nodes, and expanding root node still
doesn't work if I don't override ITreeNode's equals() and hashCode() ?
-Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: [BUG?] ITreeNode's hashCode() and equals()
Posted by tsvetelin <ts...@rushmore-digital.com>.
Hi Vjeran and Erik,
I think you will agree with me that your tree node objects are "complex"
ones (include ID, Name, List of children, link to parent node etc.). In this
case the default comparing algorithm is:
Quote: java.lang.Object documentation
"The equals method for class Object implements the most discriminating
possible equivalence relation on objects; that is, for any reference values
x and y, this method returns true if and only if x and y refer to the same
object (x==y has the value true). "
The previous sentence is the key of your problems. I suppose that you
create(load from database) your tree structure every time when the page with
contrib.Tree is rendered. In this case you create completely new instances
of the nodes but the nodes contains the same values of ID, Name, List of
children, link to parent node etc. When contrib.Tree compare the node from
ITreeStateModel(stored in previous page iteration) and the new created node
from model they will be different, because they are allocated in different
memory area and they are completely different instances of your node.
To solve this problem you can choose from the following approaches:
1. You should override the default implementation of the equals and
hashcode to provide a way for comparing 2 different objects with same
data(same ID, same Name etc.). This is standard way when you working with
"complex" objects and all collections like Map, Sets, Trees, etc in
java.util.*. This is described in the first pages of most Java books.
2. You should create your tree data structure only one time in the
application, if this is possible. For example, if have hard coded number of
nodes. In that case the default equals works fine.
Tsvetelin.
-----Original Message-----
From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
Sent: Friday, April 16, 2004 1:09 PM
To: Tapestry users
Subject: Re: [BUG?] ITreeNode's hashCode() and equals()
This caught me too.... I had to implement equals and hashCode as well
to make my custom tree node work. I wish it had been simpler to use
also.
Erik
On Apr 16, 2004, at 3:21 AM, Vjeran Marcinko wrote:
> Hi again.
> I'm flooding this mailing list with my contrib:Tree posts :-)
>
> It seems that something's wrong with contrib:Tree the way it identifies
> expanded nodes. Warner Ostine posted about this same problem few weeks
> ago.
> Anyway, I created my own implementation of ITreeNode and root node
> doesn't
> get expanded, same as Warner experienced. I was doing some digging and
> problem is that when root node is expanded it is stored in
> SimpleTreeStateModel inside internal HashSet as some TreePath object,
> but
> when tree gets rendered it instantiates new TreePath for same root
> node and
> tries to find out if this node is expanded by searching this HashSet.
> And
> normally, it doesn't find it so it renders this root node closed, thus
> root
> node can never expand.
>
> In all the working examples that I've seen, ITreeNode's implementations
> (FileSystem, TestTreeNode, Warner's solution) gets around this problem
> by
> overriding equals() and hashCode() methods with node's name comparison.
> Although this would probably be sufficient for most cases, I think that
> differentiation between node objects should not be on the basis of
> their
> names. In fact, I'm sure it is not suposed to be that way, since when
> someone implements his own ITreeNode, he expects it will work, but it
> doesn't as long as he doesn't override equals() and hashCode() with
> name
> comparison inside.
>
> -Vjeran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: [BUG?] ITreeNode's hashCode() and equals()
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
This caught me too.... I had to implement equals and hashCode as well
to make my custom tree node work. I wish it had been simpler to use
also.
Erik
On Apr 16, 2004, at 3:21 AM, Vjeran Marcinko wrote:
> Hi again.
> I'm flooding this mailing list with my contrib:Tree posts :-)
>
> It seems that something's wrong with contrib:Tree the way it identifies
> expanded nodes. Warner Ostine posted about this same problem few weeks
> ago.
> Anyway, I created my own implementation of ITreeNode and root node
> doesn't
> get expanded, same as Warner experienced. I was doing some digging and
> problem is that when root node is expanded it is stored in
> SimpleTreeStateModel inside internal HashSet as some TreePath object,
> but
> when tree gets rendered it instantiates new TreePath for same root
> node and
> tries to find out if this node is expanded by searching this HashSet.
> And
> normally, it doesn't find it so it renders this root node closed, thus
> root
> node can never expand.
>
> In all the working examples that I've seen, ITreeNode's implementations
> (FileSystem, TestTreeNode, Warner's solution) gets around this problem
> by
> overriding equals() and hashCode() methods with node's name comparison.
> Although this would probably be sufficient for most cases, I think that
> differentiation between node objects should not be on the basis of
> their
> names. In fact, I'm sure it is not suposed to be that way, since when
> someone implements his own ITreeNode, he expects it will work, but it
> doesn't as long as he doesn't override equals() and hashCode() with
> name
> comparison inside.
>
> -Vjeran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org