Yeah, components in the session like that is a problem, agreed. We should look at how we can support the existing API though. For instance by holding references to the component paths instead of the components themselves. The problem with flash messages now is that they solve exactly the same problem as what feedbackmessages should solve. If we keep them in our code base, it will be very difficult to remove them again. I think that would be a very, very bad idea. So, my proposal is to get rid of flash messages as a core API element asap, and look at improving feedback messages so that they solve the thing that flash messages solves.
Eelco On 3/23/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > but that just means that you rewrite feedback messages so that they are as > flash now > Just a matter of where you start. > > And feedbackmessages are hold on to in a page now so they should be removed > from there. > And feedbackmessage are bound to a component. And that is also what you > don't want > if they are hold on to over pages. Because then we have a mem leak. > > > johan > > > On 3/23/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote: > > Then you don't get my point. I say keep feedback, but let it work like > > flash. We want (or we should want) the possible detail of feedback > > messages (level and filtering), but we want the retention of flash > > messages. > > > > Eelco > > > > > > On 3/23/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > hmm if i read this thread > > > Then i would say.. remove the feedback. And keep the flash. > > > Flash seems to work the way we want and feedback doesn't > > > > > > johan > > > > > > > > > > > > On 3/23/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > > 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?cmdlnk&kid0944&bid$1720&dat1642 > > > _______________________________________________ > > > Wicket-develop mailing list > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > ------------------------------------------------------- > > 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?cmdlnk&kid0944&bid$1720&dat1642 > > _______________________________________________ > > Wicket-develop mailing list > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > ------------------------------------------------------- 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
