I assumed the action phase would dereference the ListItemModel (e.g. to
remove it from the map), hence dereference the LDM, and then require the
explicit detach() before rendering. Agreed that LDM is the way to go if
you're concerned about the ArrayList constructions.

On Mon, Apr 30, 2012 at 11:57 AM, Carl-Eric Menzel <cmen...@wicketbuch.de>wrote:

> On Mon, 30 Apr 2012 11:38:36 -0700
> Dan Retzlaff <dretzl...@gmail.com> wrote:
>
> > You can call LDM#detach() after the modification, but since this
> > particular implementation is so light, I'd just use
> > AbstractReadyOnlyModel instead. It doesn't cache, so detach is not
> > required.
>
> Actually, getObject() can be called pretty often, so that would incur
> the cost of creating the new List object *each time*. I would really
> use the LDM. Since in my example the LDM is passed directly into the
> ListView as its default model, the ListView will take care of
> detaching [1].
>
> cmagnollay, that means that on each render you should simply see
> whatever is currently in your map, so it should be up to date on its
> own without further action.
>
> An LDM calls the load() method the first time its getObject() is
> called. The value you return from load() will be cached until detach()
> is called on the LDM. The normal usecase is to do an expensive
> operation (load from DB, create a lot of objects, etc) only once in a
> request but to still have fresh data in each request. Also it reduces
> session size because the cached data is not kept between requests.
>
> Hope this helps!
> Carl-Eric
>
> [1] Carl-Eric's rule of detaching models: *always* do one of the
>    following:
>      - detach the model yourself
>      - pass the model to one of your child components or your
>        superclass, thus making it that code's responsibility.
>
>    You never know what model implementation you might be getting as a
>    parameter. Be nice to whoever calls you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to