Is it possile to do what you need by overriding org.apache.wicket.protocol.http.WebSession.cleanupFeedbackMessages() and/or cleanupComponentFeedbackMessages() ? I.e. you can keep the feedback messages in the session until you decide to remove them.
On Sat, Nov 13, 2010 at 8:36 PM, Michal Kurtak <[email protected]>wrote: > Hi guys, > > sorry for bother you again. Is it possible to have hasErrorMessage() > and hasFeedbackMessage() non-final? Or another workaround would be to > have non-final class FeedbackMessages? What do you think about it? > > BR, > Michal > > 2010/11/11 Michal Kurtak <[email protected]>: > > Hi folks, > > > > I try to implement persistent feedback messages (feedback messages > > that persist until next validate call). I would like to achieve this > > by having special attribute with persistent messages in a component > > and overriding hasErrorMessage method like this: > > > > public boolean hasErrorMessage() > > { > > return super.hasErrorMessage && hasPersistentErrorMessage(); > > } > > > > But there's a problem. Methods hasErrorMessage and hasFeedbackMessage > > in Component are final. > > I've found wicket bug related to persistent feedback messages: > > https://issues.apache.org/jira/browse/WICKET-2705. Igor Vaynberg > > wrote: > > > > feedback messages are stored in component's metadata with the components > > add new support for persistent feedback messages - these are not > > cleaned up after render > > > > form components report their errors as persistent > > form components clean their reported errors once validated > > so form component workflow looks like this: > > > > before validate - clear all reported errors > > validate - reports persistent messages > > onvalid - clear all reported errors > > onerror - do nothing, messages stay until next validation or onvalid > > > > Until this desired behavior will be implemented (as Igor wrote in 1.6) > > it would be useful to have hasErrorMessage() and hasFeedbackMessage() > > non-final, so users could implement persistent feedback messages. > > Is it possible? Thanks. > > > > BR, > > Michal > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
