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
