On 3/31/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > i am not so sure this is correct. we often deal with two page instances > inside the same request - the current one and the response page. this breaks > any kind of scoping as errors reported against current page will now make it > into response page?
About the session messages... well, they have a slightly different meaning: display whenever there is a feedback component rendered on any page. This is useful when writing generic software where you know that a message should be displayed, but you just don't know the target (e.g. at the end of a wizard). About per-page or per-request... yeah, we've been there too. If we look back at the history we can say that the page is the correct place to have it. So, what we should do is put the messages for the pages in the session, and at the start of rendering (right before attach), iterate through those messages and the ones that have components attached (are for pages) are then added to those pages. If there are messages with components that are not coupled to a page, well tough luck and discard them (those would throw an exception currently). One final thing we should fix is the fact that feedbackmessages don't get cleaned up when there are no feedback components in the page. This is a memory leak. Eelco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
