Hi,
thanks for the quick response. Just to be sure, I added code to detach
the model after changing it, but nothing changed in behavior. In this
case, LoadableDetachableModel only caches a *reference* to the
underlying java.util.List, which is shared by all instances of the
model class (it comes from a static variable). So it's expected that
detaching does not change anything in this example, though in more
realistic cases it would indeed be another way to cause a similar
effect. Sorry for the confusion.
The problem is, I think, not that the component is being marked as
*rendered*, but as *prepared for render*. From class Component:
protected void onBeforeRender()
{
setFlag(FLAG_PREPARED_FOR_RENDER, true);
onBeforeRenderChildren();
setRequestFlag(RFLAG_BEFORE_RENDER_SUPER_CALL_VERIFIED, true);
}
Note the first line. This causes subsequent invocations of
internalBeforeRender() to skip the relevant part.
Greetings,
Martin
On Wed, Jan 1, 2014 at 6:33 PM, Sven Meier <s...@meiers.net> wrote:
> Hi,
>
> if I read its javadoc correctly, #internalPrepareForRender(false) should not
> mark the page as rendered (thus the false parameter).
>
> If your link modifies the ListView's model, it should call #detach() on it.
> Otherwise it will show stale data on next rendering. This doesn't have
> anything to do with stateless pages, it is a general practice.
> Can you verify whether this is the actual problem?
>
> Regards
> Sven
>
>
> On 01/01/2014 03:51 PM, Martin Geisse wrote:
>>
>> Hi,
>>
>> first of all, sorry for double-posting. It seems like I triggered some
>> strange keyboard shortcut in Gmail before I was finished writing that
>> mail... :(
>>
>> I'm having a problem with a ListView that displays an outdated list.
>> In my test, the ListView uses a LoadableDetachableModel that "loads"
>> from a static variable just to make sure the model is independent from
>> any page instance. As far as I can tell, this problem has nothing to
>> do with the model, but with the way Wicket prepares for a request
>> listener invocation.
>>
>> The exact setup is this:
>> - the page contains a ListView and (outside of the list) a Link that
>> adds an item to the list in its onClick(). The list itself is stored
>> in a static variable.
>> - the page is stateless
>> - the page's components are created in onInitialize()
>>
>> Result:
>> The list doesn't show the most recently added item. Reloading the
>> original page shows the correct list. Note that by "reloading" I mean
>> entering the page's URL since the browser's address bar now contains
>> the request listener URL due to the page being stateless.
>>
>> This is how I think is happens:
>> - Initially rendering the page works fine. The page is then discarded
>> since it's stateless.
>> - Clicking on the link creates a new page instance to invoke the
>> link's request listener.
>> - IPageAndComponentProvider.getComponent() cannot find the link yet
>> since it is not created until onInitialize() has been called.
>> - as a consequence, it calls page.internalInitialize() and
>> internalPrepareForRender(false)
>> - this creates the link, but it also creates the ListView and prepares
>> it for rendering. This in turn polls the ListView's model and creates
>> list items. It also marks the ListView as "prepared for render", which
>> is the crucial point.
>> - The link's request listener runs and adds an item to the list.
>> - After the request listener handler, the page render handler runs
>> - That handler renders the page, including the ListView
>> - ... but it doesn't call onBeforeRender() on the ListView anymore,
>> because it's already marked as "prepared for render"! So it doesn't
>> pick up the new, up-to-date list from its model.
>>
>> I'm not sure if I'm "doing it wrong", but then it doesn't seem quite
>> right that onBeforeRender() gets called before invoking the listener,
>> but not actually before rendering. There's probably some kind of logic
>> behind the decision to run onBeforeRender() only when this hasn't yet
>> happened, right? Is there a general way to "unprepare" the component
>> in onClick()?
>>
>> Greetings,
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
