7 Replies Latest reply on Sep 26, 2008 1:37 AM by agrimm

    Converter for SortedLlist etc.

      Hi,

      I know the subject was already discussed in earlier threads, but I was wandering why there is no more generic default converter implemented. The converter could use the hashcode-methode to convert objects to string and later use the hashcode-methode to identify the returned values within the component lists.

      The tag-user can than, if requered override the hashcode-methode and he is done with it. What are you thinking about this solution?

      Hoping for a nice discussion.
      Achim Grimm

        • 1. Re: Converter for SortedLlist etc.
          shadowcreeper

          Or better yet, the toString() method (overriding either the hashCode or the toString method should work in this case since the default toString is just the class name followed by the hashCode).

          • 2. Re: Converter for SortedLlist etc.
            shadowcreeper

            Still, identical hashCode does not mean identical objects. A better idea would be to expect a List (or Set, Array, whatever) of Serializable objects.

            • 3. Re: Converter for SortedLlist etc.

               

              A better idea would be to expect a List (or Set, Array, whatever) of Serializable objects.

              What would be the benefit of serializable objects.

              I think you are right, with the hashCode and toString-method. This would be a better way to identity the objects.

              Still, identical hashCode does not mean identical objects.

              Well you, could argument, that the normally identical objects don't need to be sorted. I think the trick would be, to implement the hashcode/toString-methode in a way, that the objects to differ. Maybe with a unique objectID.

              • 4. Re: Converter for SortedLlist etc.
                shadowcreeper

                Serializables can theoretically be serialized into Strings. If you use that as CDATA, it could then be deserialized into the object.

                • 5. Re: Converter for SortedLlist etc.

                  Theoretically, yes. But still: "What would be the benefit of serializable objects?" On the other hand, you have got a lot of server-client-trafiic.

                  • 6. Re: Converter for SortedLlist etc.
                    shadowcreeper

                    Like I said above, it makes the converter simple, just serialize and deserialize. Plus no worries about matching hashCode() for non equals() objects. No need for it to keep a copy of any lists either.

                    Yes, it can add a bit to the initial loading of the items but if you are worried about that just create your own converter. Most of mine just return the PK from the database record (very small) and "deserialize" by retrieving the record from hibernate with the given PK. Also, my hashCode overrides usually just return PK too, so it *is* unique (but that's just me).

                    • 7. Re: Converter for SortedLlist etc.

                      Okay,

                      so let's say both ways have there ups and downs. ;-) I can agree to you, that you could use your DB-PK to "deserialize" the object. But this only is an option for already persisted objects. But this can't be done with backingbeans placed in the users session. These backingbeans can become quite large and multiple references. So I don't think deserializing these objects is a reliably way to identified the returned order.

                      By the way. What do the RF-people think? Did you have this throught already?