to start: the core problem is how does wicket identify which row you
clicked in a listview? the url contains the component path of the link
you clicked. a listview item only keeps the index of the element in
the list, so when you click that link the sequence is

link.getmodel()->listitem_the_link_is_in.getmodel()->listview.getmodel().get(listitem.index)

listviews are for lists. a list is a collection where elements are
uniquely identified by their index - ie the PK of a list entry is its
index.

for a collection of elements backed by a list it is fine to use ListView.

lets look at your code:

@org.hibernate.annotations.CollectionOfElements
private Collection<User> users = new ArrayList<User>();

this is not a list - this is a collection. what will hibernate use to
back this when it loads? will it still be a List or a Set?

for such a mapping you cannot use a listview because the order in
which these elements are loaded is not guaranteed and so this is not a
list. what this means is that you render the list, click a link in the
third row - but when wicket will try to load the third element from
the list it is no longer guaranteed to be the same - so it will load
the wrong one - very bad. eg user clicks to delete user "bob" but
deletes user "jon" instead.

now, not sure if this works with collectionofelements, but if you did
something like this:
@org.hibernate.annotations.CollectionOfElements
@org.hibernate.annotations.IndexColumn(name="idx")
private List<User> users = new ArrayList<User>();

then this would be a list and you could use a listview with this.
however, because of the concurrent nature of the web you should always
use optimistic locking when working with lists.

if you have a @OneToMany then you should not use a listview because,
once again, the elements returned are not a true list - each entry has
its own PK and does not use it's index in the list as the PK. for that
you should use a dataview and return a model that can load the entity
by its true PK.

-igor

On Wed, Aug 5, 2009 at 11:02 AM, Troy Cauble<[email protected]> wrote:
> Short version:
> What's the right way to View & Model lists of Hibernate data that
> are not Entities (@CollectionsOfElements) and already loaded via
> an Entity?
>
> What if they are Entities, but are already loaded via another Entity
> (@OneToMany)?
>
> Long version:
> Absorbing the mantra "ListView is bad for database data", I was looking into
> converting some ListViews into DataViews.  But these list items are
> not Hibernate
> Entities.  They're  CollectionsOfElements belonging to an Entity.
>
> @Entity
> class Foo
> {
>       �[email protected]
>        private Collection<User> users = new ArrayList<User>();
>        ...
> }
>
> So the example
>
> class UsersProvider implements IDataProvider
> {
>        public Iterator iterator(int first, int count)
>        {
>
> ((MyApplication)Application.get()).getUserDao().iterator(first,
> count);
>        }
>
>        public int size()
>        {
>                ((MyApplication)Application.get()).getUserDao().getCount();
>        }
>
>        public IModel model(Object object)
>        {
>                return new DetachableUserModel((User)object);
>        }
>  }
>
> doesn't really fit.  My "Users" are a list hanging off an Entity that is
> loaded from the database.  My "Users" don't have a unique ID for
> their own DetachableUserModel.
>
> So, should I create an IDataProvider that references the higher
> level Entity Foo?  Or should I stick with ListView and ::setList()
> (after Foo's LDM refreshes the list)?  Something else?
>
> Is the answer the same when the data *are* Entities, but are already
> loaded via the LDM of another Entity?
>
> @Entity
> class Foo
> {
>       �...@onetomany
>        private Set<OtherEntity> = new TreeSet<OtherEntity>();
>        ...
> }
>
> Thanks,
> -troy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to