I don't have much preference for either (just didn't like to add 4
bytes to all components). Both have their merits:
- separate message queue (thread local) that stores in pages (you can
get to the page by performing component.getPage()) at the end of the
request
- store in session
Both have their pro's and con's. I'd suggest that we just choose the
one with the least problems, make sure we keep current functionality
working. Any fancy stuff can go into the next release. If we want to
'upgrade' our validation messages.
Depending on how we would clean up the messages in session, we might
loose the ability to store messages for pages that are rendered in a
future, but not right away. But I think that's highly hypothetical.
The advantage of the session based solution is that it will save a
little bit of memory, and is slightly cheaper in the processing
(though that might be offset again because it needs synchronization).
But the biggest pro for the session solution is that it will be
cleaner and easier to follow. If we can get a satisfying way to clean
the messages up that is.
I could use a generic message mechanism in Wicket, with user
controlled removal of the messages (for todo's, messages that need to
stay for several pages until the issue is resolved, etc). But that
doesn't have to be in wicket 1.3 imo, if at all.
Why not? Maybe all we need is an extra abstraction... if you have an
idea of what you want, why postpone it (you know the Dutch saying,
'from uitstel komt afstel')? I cannot imagine it'll be that much more
work. But we need a good description of what you mean.
Eelco
