This could be a bug. Could you create a quickstart please and attach it
to a JIRA issue?
Many thanks
Sven
On 01/01/2014 07:38 PM, Martin Geisse wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
