You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/03/28 11:40:34 UTC
[CForms] Repeater: why not hashCode for id?
This might be a stupid question, but why does the repeater need an own
identity attribute on the objects contained in the list? If I bind my
form to beans I have the hashCode of these objects which should be unique.
But in all our samples we use an own "id" property. Could we simplify
this or is there something that prevents this? Or doesn't it make sense?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Repeater: why not hashCode for id?
Posted by Antonio Gallardo <ag...@agssa.net>.
On Lun, 28 de Marzo de 2005, 3:40, Carsten Ziegeler dijo:
> This might be a stupid question, but why does the repeater need an own
> identity attribute on the objects contained in the list? If I bind my
> form to beans I have the hashCode of these objects which should be unique.
>
> But in all our samples we use an own "id" property. Could we simplify
> this or is there something that prevents this? Or doesn't it make sense?
If you are refering to <fb:identity>, I implemented it, because in some
cases we need more than 1 value to identify a row in a repeater. More info
here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107811213016802&w=2
Before <fb:identity>, was imposible to diferentiate 2 rows in a repeater
that are diferent by more than 1 field. There was an attribute that was
able to catch only one field and in some cases this is not enough.
The oposite, make a default where all the field in the row are "unique"
seems like not a good idea. This can be done by the hashcode. But, seems
like defining a DB tables where all fields are part of the primary key of
the given table. And this is not recommended at all.
Looking forward for your comments, perhaps we can find a better way to do
that. ;-)
Best Regards,
Antonio Gallardo.
>
> Carsten
>
> --
> Carsten Ziegeler - Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.org/weblogs/rael/
>
Re: [CForms] Repeater: why not hashCode for id?
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 30 de Marzo de 2005, 3:47, Carsten Ziegeler dijo:
> Although I think that Sylvains idea is a better long term solution, it
> seems complicated and will take some time until it's done.
>
> I still think that using the hashCode of an object is a valid solution
> for many use cases. The only problem currently is that I can't use the
> hashCode directly, so in the binding I can't just write:
>
> <fb:identity>
> <fb:value id="id" path="hashCode"/>
> </fb:identity>
>
> as the path would be resolved to a getHashCode() method in the bean that
> obviously doesn't exist. In fact this is a general problem if your
> method is not named properly. What about adding the possibility to call
> a method?
>
> <fb:identity>
> <fb:value id="id" method="hashCode"/>
> </fb:identity>
This is a posible extension of the current approach, even this can
extended the current model to use what ever method not only hashcode:
<fb:value id="id" method="myMethod"/>
But, I am blind since I don't see where this can be useful.
Best Regards,
Antonio Gallardo.
Re: [CForms] Repeater: why not hashCode for id?
Posted by Carsten Ziegeler <cz...@apache.org>.
Although I think that Sylvains idea is a better long term solution, it
seems complicated and will take some time until it's done.
I still think that using the hashCode of an object is a valid solution
for many use cases. The only problem currently is that I can't use the
hashCode directly, so in the binding I can't just write:
<fb:identity>
<fb:value id="id" path="hashCode"/>
</fb:identity>
as the path would be resolved to a getHashCode() method in the bean that
obviously doesn't exist. In fact this is a general problem if your
method is not named properly. What about adding the possibility to call
a method?
<fb:identity>
<fb:value id="id" method="hashCode"/>
</fb:identity>
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Repeater: why not hashCode for id?
Posted by Ben Pope <be...@gmail.com>.
Sylvain Wallez wrote:
> Ben Pope wrote:
>
>> Sylvain Wallez wrote:
>>
>>> No, no identity at all! Since you replay the add/move/delete events,
>>> you just need to be able to remove/add items at specific positions.
>>> That means that the underlying collection should be a java.util.list
>>> or a dom Element.
>>>
>>> But actually this can be even simpler and we don't need this
>>> record/replay thing :-)
>>>
>>> Have a look at the dynamic template sample [1] and play with
>>> add/delete/move actions: each row has an ID which indicates the row's
>>> creation order. In the case of binding, we won't use exactly use this
>>> ID, but store in rows the position in the original collection as an
>>> attribute (e.g. "load-position").
>>>
>>> When the repeater is saved, with this information it's easy to know
>>> where and how to bind its rows:
>>> - if the "load-position" attribute exists, we bind to the
>>> corresponding object in the original collection,
>>> - if the "load-position" attribute doesn't exist, that means the row
>>> is newly created, and we therefore create a new object to save it.
>>>
>>> Row moves can be managed either by reordering the original collection
>>> or by creating a new collection to which objects will be added.
>>>
>>> I like this more, and this has the potential to kill both the current
>>> (complicated) repeater binding and also the simple-repeater binding
>>> which becomes useless :-)
>>>
>>> Sylvain
>>>
>>> [1] http://localhost:8888/samples/blocks/forms/do-dynaRepeater.flow
>>
>>
>>
>> What if the underlying structure can have different (previous) rows
>> removed from it between when you load the model and save it back?
>>
>> Obviously you would usually lock the back end model, but you should
>> only need to lock the rows that you have retrieved, and deal with
>> unique IDs in a common manner.
>>
>> If you're just playing back positions and actions over the model, then
>> you prevent simultaneous access to the data. Either that or you just
>> push the complications into the users model.
>>
>> I suppose you could just tag old rows as dead, instead of removing
>> them. And then clean up when nothing is locked.
>>
>> Having the identity solved this problem. Or have I missed something?
>
>
>
> It all depends if you consider the repeater and the underlying
> collection to be part of the application data model or just a
> convenience container to show a set of independent objects to the user.
>
> If it's a application-level collection, then the repeater should be
> considered just the same as finer-grained objects and locked as a whole,
> or checked for concurrent modification to prevent lost update if locking
> isn't an option.
With the identity mapping, as it is now, it's possible to select a
subset of the children contained within a node:
<fruits>
<fruit id="0">
<name>Apple</name>
<colour>green</colour>
</fruit>
<fruit id="1">
<name>Orange</name>
<colour>orange</colour>
</fruit>
<fruit id="2">
<name>Mango</name>
<colour>orange</colour>
</fruit>
<fb:reapeater parent-path="fruits" row-path="fruit[colour='orange']"
row-path-insert="fruit">
So now I can modify orange fruits without locking apple (or any other
non-orange fruit). You could easily modify green fruit, as long as the
id is being tracked.
If I start modifying orange fruit, then you start modifying green fruit
by deleting apple, then I save the model back, obviously we have a
problem as the positions are now off-by-one. So unless the replaying
can take into account simultaneous accesses, all of the ones that
happend since the form was loaded (what if using hibernate!), we've lost
functionality.
> If it's just a holder, then only individual rows are bound and saved to
> the underlying storage. Modified rows lead to an update and new rows
> lead to an insert. There is a problem though for deleted rows as the
> repeater does not track rows that have been deleted (and the
> corresponding IDs). But if the repeater is just a dumb container,
> deletion can occur as soon as the users triggers the delete action.
>
> Does this answer your concerns, or did I missed something also?
I'm concerned that functionality has been lost - perhaps it's bad
practice to bind directly to the back end model. Perhaps it should be
discouraged in favour of having the user always deal with an
intermediate layer which, for example, uses an identity. So surely by
simplifying the repeater, you're just pushing the complicated identity
stuff to the user?
I know that the repeater is a complicated beast as I've been trying to
modify it for my own purposes. I'd love for there to be a much easier
way of dealing with the binding, I just feel that using the identity is
a very robust way of doing it and it's better to have it in the binding
framework than the users code.
Thanks for your time,
Ben.
Re: [CForms] Repeater: why not hashCode for id?
Posted by Sylvain Wallez <sy...@apache.org>.
Ben Pope wrote:
> Sylvain Wallez wrote:
>
>> No, no identity at all! Since you replay the add/move/delete events,
>> you just need to be able to remove/add items at specific positions.
>> That means that the underlying collection should be a java.util.list
>> or a dom Element.
>>
>> But actually this can be even simpler and we don't need this
>> record/replay thing :-)
>>
>> Have a look at the dynamic template sample [1] and play with
>> add/delete/move actions: each row has an ID which indicates the row's
>> creation order. In the case of binding, we won't use exactly use this
>> ID, but store in rows the position in the original collection as an
>> attribute (e.g. "load-position").
>>
>> When the repeater is saved, with this information it's easy to know
>> where and how to bind its rows:
>> - if the "load-position" attribute exists, we bind to the
>> corresponding object in the original collection,
>> - if the "load-position" attribute doesn't exist, that means the row
>> is newly created, and we therefore create a new object to save it.
>>
>> Row moves can be managed either by reordering the original collection
>> or by creating a new collection to which objects will be added.
>>
>> I like this more, and this has the potential to kill both the current
>> (complicated) repeater binding and also the simple-repeater binding
>> which becomes useless :-)
>>
>> Sylvain
>>
>> [1] http://localhost:8888/samples/blocks/forms/do-dynaRepeater.flow
>
>
> What if the underlying structure can have different (previous) rows
> removed from it between when you load the model and save it back?
>
> Obviously you would usually lock the back end model, but you should
> only need to lock the rows that you have retrieved, and deal with
> unique IDs in a common manner.
>
> If you're just playing back positions and actions over the model, then
> you prevent simultaneous access to the data. Either that or you just
> push the complications into the users model.
>
> I suppose you could just tag old rows as dead, instead of removing
> them. And then clean up when nothing is locked.
>
> Having the identity solved this problem. Or have I missed something?
It all depends if you consider the repeater and the underlying
collection to be part of the application data model or just a
convenience container to show a set of independent objects to the user.
If it's a application-level collection, then the repeater should be
considered just the same as finer-grained objects and locked as a whole,
or checked for concurrent modification to prevent lost update if locking
isn't an option.
If it's just a holder, then only individual rows are bound and saved to
the underlying storage. Modified rows lead to an update and new rows
lead to an insert. There is a problem though for deleted rows as the
repeater does not track rows that have been deleted (and the
corresponding IDs). But if the repeater is just a dumb container,
deletion can occur as soon as the users triggers the delete action.
Does this answer your concerns, or did I missed something also?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [CForms] Repeater: why not hashCode for id?
Posted by Ben Pope <be...@gmail.com>.
Sylvain Wallez wrote:
> No, no identity at all! Since you replay the add/move/delete events, you
> just need to be able to remove/add items at specific positions. That
> means that the underlying collection should be a java.util.list or a dom
> Element.
>
> But actually this can be even simpler and we don't need this
> record/replay thing :-)
>
> Have a look at the dynamic template sample [1] and play with
> add/delete/move actions: each row has an ID which indicates the row's
> creation order. In the case of binding, we won't use exactly use this
> ID, but store in rows the position in the original collection as an
> attribute (e.g. "load-position").
>
> When the repeater is saved, with this information it's easy to know
> where and how to bind its rows:
> - if the "load-position" attribute exists, we bind to the corresponding
> object in the original collection,
> - if the "load-position" attribute doesn't exist, that means the row is
> newly created, and we therefore create a new object to save it.
>
> Row moves can be managed either by reordering the original collection or
> by creating a new collection to which objects will be added.
>
> I like this more, and this has the potential to kill both the current
> (complicated) repeater binding and also the simple-repeater binding
> which becomes useless :-)
>
> Sylvain
>
> [1] http://localhost:8888/samples/blocks/forms/do-dynaRepeater.flow
What if the underlying structure can have different (previous) rows
removed from it between when you load the model and save it back?
Obviously you would usually lock the back end model, but you should only
need to lock the rows that you have retrieved, and deal with unique IDs
in a common manner.
If you're just playing back positions and actions over the model, then
you prevent simultaneous access to the data. Either that or you just
push the complications into the users model.
I suppose you could just tag old rows as dead, instead of removing them.
And then clean up when nothing is locked.
Having the identity solved this problem. Or have I missed something?
Ben
Re: [CForms] Repeater: why not hashCode for id?
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>
>>>> Yepp, that's true - but usually for your own business objects you know
>>>> if hashCode is unique or not.
>>>>
>>>>
>>>>
>>>
>>> Hmm... *you* know, but I don't think all people take care of that!
>>>
>>>
>>
>> Yes, that's true. Now, I don't want that the repeater always relies on
>> hashCode but
>> perhaps as a default - if no identity is given for example.
>> And everything else stays the same. But perhaps your suggestions below
>> are even better!
>>
>>
>>
>>> No, the problem for me was time and lack of real need ;-)
>>>
>>
>> :)
>>
>>
>>
>>> Now there may be a problem if the objects used to load the form need
>>> to different from those used to save it, either because they're big
>>> (and we don't want them to stay around until continuation expiration)
>>> or because of transactional needs (e.g. Hibernate objects attached to
>>> different sessions).
>>>
>>> Another idea I suggested (just comes back to my mind) is to have the
>>> repeater record the row additions/moves/deletions occuring since the
>>> last time it was loaded by the binding, and then have the binding
>>> replay these events on the target collection on save. This avoids
>>> keeping the objects around and also handles row deletions which my
>>> other proposal doesn't.
>>>
>>> That may be a better solution. WDYT?
>>>
>>>
>>
>> Yes, sounds very good to me! But in this case you still need an identity
>> property for replaying, or?
>>
>>
>
> No, no identity at all! Since you replay the add/move/delete events, you
> just need to be able to remove/add items at specific positions. That
> means that the underlying collection should be a java.util.list or a dom
> Element.
>
> But actually this can be even simpler and we don't need this
> record/replay thing :-)
>
> Have a look at the dynamic template sample [1] and play with
> add/delete/move actions: each row has an ID which indicates the row's
> creation order. In the case of binding, we won't use exactly use this
> ID, but store in rows the position in the original collection as an
> attribute (e.g. "load-position").
>
> When the repeater is saved, with this information it's easy to know
> where and how to bind its rows:
> - if the "load-position" attribute exists, we bind to the corresponding
> object in the original collection,
> - if the "load-position" attribute doesn't exist, that means the row is
> newly created, and we therefore create a new object to save it.
>
> Row moves can be managed either by reordering the original collection or
> by creating a new collection to which objects will be added.
>
> I like this more, and this has the potential to kill both the current
> (complicated) repeater binding and also the simple-repeater binding
> which becomes useless :-)
After reading all suggestions this makes the most sense (for me) :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [CForms] Repeater: why not hashCode for id?
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>>Yepp, that's true - but usually for your own business objects you know
>>>if hashCode is unique or not.
>>>
>>>
>>>
>>>
>>Hmm... *you* know, but I don't think all people take care of that!
>>
>>
>>
>Yes, that's true. Now, I don't want that the repeater always relies on
>hashCode but
>perhaps as a default - if no identity is given for example.
>And everything else stays the same. But perhaps your suggestions below
>are even better!
>
>
>
>>No, the problem for me was time and lack of real need ;-)
>>
>>
>:)
>
>
>
>>Now there may be a problem if the objects used to load the form need to
>>different from those used to save it, either because they're big (and we
>>don't want them to stay around until continuation expiration) or because
>>of transactional needs (e.g. Hibernate objects attached to different
>>sessions).
>>
>>Another idea I suggested (just comes back to my mind) is to have the
>>repeater record the row additions/moves/deletions occuring since the
>>last time it was loaded by the binding, and then have the binding replay
>>these events on the target collection on save. This avoids keeping the
>>objects around and also handles row deletions which my other proposal
>>doesn't.
>>
>>That may be a better solution. WDYT?
>>
>>
>>
>Yes, sounds very good to me! But in this case you still need an identity
>property for replaying, or?
>
>
No, no identity at all! Since you replay the add/move/delete events, you
just need to be able to remove/add items at specific positions. That
means that the underlying collection should be a java.util.list or a dom
Element.
But actually this can be even simpler and we don't need this
record/replay thing :-)
Have a look at the dynamic template sample [1] and play with
add/delete/move actions: each row has an ID which indicates the row's
creation order. In the case of binding, we won't use exactly use this
ID, but store in rows the position in the original collection as an
attribute (e.g. "load-position").
When the repeater is saved, with this information it's easy to know
where and how to bind its rows:
- if the "load-position" attribute exists, we bind to the corresponding
object in the original collection,
- if the "load-position" attribute doesn't exist, that means the row is
newly created, and we therefore create a new object to save it.
Row moves can be managed either by reordering the original collection or
by creating a new collection to which objects will be added.
I like this more, and this has the potential to kill both the current
(complicated) repeater binding and also the simple-repeater binding
which becomes useless :-)
Sylvain
[1] http://localhost:8888/samples/blocks/forms/do-dynaRepeater.flow
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [CForms] Repeater: why not hashCode for id?
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>>
>>Yepp, that's true - but usually for your own business objects you know
>>if hashCode is unique or not.
>>
>>
>
>
> Hmm... *you* know, but I don't think all people take care of that!
>
Yes, that's true. Now, I don't want that the repeater always relies on
hashCode but
perhaps as a default - if no identity is given for example.
And everything else stays the same. But perhaps your suggestions below
are even better!
>
> No, the problem for me was time and lack of real need ;-)
>
:)
> Now there may be a problem if the objects used to load the form need to
> different from those used to save it, either because they're big (and we
> don't want them to stay around until continuation expiration) or because
> of transactional needs (e.g. Hibernate objects attached to different
> sessions).
>
> Another idea I suggested (just comes back to my mind) is to have the
> repeater record the row additions/moves/deletions occuring since the
> last time it was loaded by the binding, and then have the binding replay
> these events on the target collection on save. This avoids keeping the
> objects around and also handles row deletions which my other proposal
> doesn't.
>
> That may be a better solution. WDYT?
>
Yes, sounds very good to me! But in this case you still need an identity
property for replaying, or?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Repeater: why not hashCode for id?
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>hashCodes are not supposed to be unique, even if the default
>>implementation in Object /may/ use the memory address as hashCode!
>>
>>
>>
>Yepp, that's true - but usually for your own business objects you know
>if hashCode is unique or not.
>
>
Hmm... *you* know, but I don't think all people take care of that!
>>Personally, I find this repeater binding stuff very complicated. I cases
>>where all data of the underlying application data are displayed in a
>>form, I use the simple-repeater binding that first destroys the
>>collection before recreating it from scratch. Up to now, it has
>>fulfilled 80% of my needs.
>>
>>
>Ah, didn't know the simple-repeater binding, but in my use-cases I can't
>destroy the objects and recreate them :(
>
>
>
>>A suggestion I made once to simplify the repeater binding when using
>>simple-repeater isn't possible is to store the objects as attributes of
>>the rows they are bound to during load (see
>>widget.{get/set}Attribute()), and later use that information to recreate
>>the collection on save. I guess this is similar to what you suggest,
>>except it would use strict pointer equality (i.e. '==') instead of
>>hascodes which may not be unique.
>>
>>
>Yes, right. I find it really annoying to add an identity property just
>because the repeater requires it. This means that the forms framework
>has an influence on my data model and that is simply bad.
>So are there any problems with implementing your suggestion?
>
>
No, the problem for me was time and lack of real need ;-)
Now there may be a problem if the objects used to load the form need to
different from those used to save it, either because they're big (and we
don't want them to stay around until continuation expiration) or because
of transactional needs (e.g. Hibernate objects attached to different
sessions).
Another idea I suggested (just comes back to my mind) is to have the
repeater record the row additions/moves/deletions occuring since the
last time it was loaded by the binding, and then have the binding replay
these events on the target collection on save. This avoids keeping the
objects around and also handles row deletions which my other proposal
doesn't.
That may be a better solution. WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [CForms] Repeater: why not hashCode for id?
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Mar 28, 2005, at 12:12 PM, Carsten Ziegeler wrote:
> Glen Ezkovich wrote:
>> On Mar 28, 2005, at 6:35 AM, Carsten Ziegeler wrote:
>
>>
>> I'm sure you are aware of this and take this as you will, the general
>> contract for hashCode states that
>> "If two objects are equal according to the equals(Object) method,
>> then
>> calling the hashCode method on each of the two objects must produce
>> the
>> same integer result."
>>
>> So 2 distinct objects may have the same hashCode and it may be
>> necessary to bind 2 equal objects.
>>
> Yes, that's true - but I - in the role of the application developer -
> know how hashCode works for my own objects. And from the JavaDocs for
> Object:
> "As much as is reasonably practical, the hashCode method defined by
> class Object does return distinct integers for distinct objects."
>
> So unless you have overwritten hashCode everything is fine.
Exactly. If I override equals, I override hashCode and I override
equals for just about any class I would use to bind. (its a habit...
what can I say)
>
> Now, I don't want that the repeater always relies on hashCode but
> perhaps as a default - if no identity is given for example. And
> everything else stays the same.
I can live with this but the documentation needs to be very explicit
with this. It seems like an error waiting to happen. Sylvain's solution
seems safer.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: [CForms] Repeater: why not hashCode for id?
Posted by Carsten Ziegeler <cz...@apache.org>.
Glen Ezkovich wrote:
> On Mar 28, 2005, at 6:35 AM, Carsten Ziegeler wrote:
>
> I'm sure you are aware of this and take this as you will, the general
> contract for hashCode states that
> "If two objects are equal according to the equals(Object) method, then
> calling the hashCode method on each of the two objects must produce the
> same integer result."
>
> So 2 distinct objects may have the same hashCode and it may be
> necessary to bind 2 equal objects.
>
Yes, that's true - but I - in the role of the application developer -
know how hashCode works for my own objects. And from the JavaDocs for
Object:
"As much as is reasonably practical, the hashCode method defined by
class Object does return distinct integers for distinct objects."
So unless you have overwritten hashCode everything is fine.
Now, I don't want that the repeater always relies on hashCode but
perhaps as a default - if no identity is given for example. And
everything else stays the same.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Repeater: why not hashCode for id?
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Mar 28, 2005, at 6:35 AM, Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>> Carsten Ziegeler wrote:
>>
>>
>> hashCodes are not supposed to be unique, even if the default
>> implementation in Object /may/ use the memory address as hashCode!
>>
> Yepp, that's true - but usually for your own business objects you know
> if hashCode is unique or not.
I'm sure you are aware of this and take this as you will, the general
contract for hashCode states that
"If two objects are equal according to the equals(Object) method, then
calling the hashCode method on each of the two objects must produce the
same integer result."
So 2 distinct objects may have the same hashCode and it may be
necessary to bind 2 equal objects.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: [CForms] Repeater: why not hashCode for id?
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>
> hashCodes are not supposed to be unique, even if the default
> implementation in Object /may/ use the memory address as hashCode!
>
Yepp, that's true - but usually for your own business objects you know
if hashCode is unique or not.
> Personally, I find this repeater binding stuff very complicated. I cases
> where all data of the underlying application data are displayed in a
> form, I use the simple-repeater binding that first destroys the
> collection before recreating it from scratch. Up to now, it has
> fulfilled 80% of my needs.
Ah, didn't know the simple-repeater binding, but in my use-cases I can't
destroy the objects and recreate them :(
>
> A suggestion I made once to simplify the repeater binding when using
> simple-repeater isn't possible is to store the objects as attributes of
> the rows they are bound to during load (see
> widget.{get/set}Attribute()), and later use that information to recreate
> the collection on save. I guess this is similar to what you suggest,
> except it would use strict pointer equality (i.e. '==') instead of
> hascodes which may not be unique.
>
Yes, right. I find it really annoying to add an identity property just
because the repeater requires it. This means that the forms framework
has an influence on my data model and that is simply bad.
So are there any problems with implementing your suggestion?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Repeater: why not hashCode for id?
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>This might be a stupid question, but why does the repeater need an own
>identity attribute on the objects contained in the list? If I bind my
>form to beans I have the hashCode of these objects which should be unique.
>
>
hashCodes are not supposed to be unique, even if the default
implementation in Object /may/ use the memory address as hashCode!
>But in all our samples we use an own "id" property. Could we simplify
>this or is there something that prevents this? Or doesn't it make sense?
>
>
Personally, I find this repeater binding stuff very complicated. I cases
where all data of the underlying application data are displayed in a
form, I use the simple-repeater binding that first destroys the
collection before recreating it from scratch. Up to now, it has
fulfilled 80% of my needs.
A suggestion I made once to simplify the repeater binding when using
simple-repeater isn't possible is to store the objects as attributes of
the rows they are bound to during load (see
widget.{get/set}Attribute()), and later use that information to recreate
the collection on save. I guess this is similar to what you suggest,
except it would use strict pointer equality (i.e. '==') instead of
hascodes which may not be unique.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director