On 3/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > i set out to achieve exactly what i achieved. as you point out feedback > messages do not last across requests. so lets say i am on edit page and i > just clicked save. the edit page returns me to the list page, i would like > to see a confirmation message on the list page that whatever i was editing > has been successfully saved. this message should be set by the edit page, > but displayed on the list page and should last across any redirects we do to > get to the list page from the edit page. furthermore, once it is displayed > it should not be displayed again.
Yes. Like CDApp /used to do/ with feedback messages. Unfortunately we have a long history with breaking/ fixing/ breaking and fixing feedbackmessages again, and CDApp is broken again due to the fact that onBeginRequest never had clear semantics, and feedbackmessages are queried before that method is called. > these messages arent really meant to be "scoped" because there is no scope > really. what i would like to maybe see is a error/info/warn levels like we > have with feedback messages. i didnt do that because i couldnt decide on a > good api, should i introduce flashInfo/flashWarn/flashError into component > or should i add a boolean to our info/warn/error methods to tell it whether > to store the message in flash scope or not? another thing i couldnt decide > on is whether or not to make our feedbackpanel also display the messages in > the flash store. > > because i couldnt decide on those points above i implemented the simplest > possible solution. if you see a way to have this functionality without the > api bloat im all ears. Well, the thing is that you are really trying to fix feedback messages. Feedback messages /should/ work like those flash messages, and the fact that they currently don't is faulty. I think we should remove the flash methods again - even though there is this slight hype factor to them ;) - and change the feedback messages implementation and put them in the session instead of the page. I don't really know what tricky details that could involve - I'm too bloody bussy writing that bloody rotten book -, but that would be the idea. > i upgraded wicket-phonebook to use this so you can check it out there. Yeah. CDApp has exactly the same needs. Probably every CRUD or app with master/ detail pages out there. Eelco ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
