it isnt too expensive if you store it in the metadata. i think this was all discussed before we had metadata support.
-igor On 4/21/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Can there now never be hanging feedback messages? > IF a component didn't have a page anymore (removed by listview or something > like that) > but it did report something. > Or if the Request Page did report an error but there was another Page set as > the response... > > Also the clear of FeedbackMessages which does this: > messages.remove(message); > > one by one for all the messages is pretty expensive because we use a > CopyOnWriteList.. You're right, we should fix that. > But in the end we have 2 types of feedback right? > Session feedback messsages and Page or better said: Request feedback > messages > Why aren't we storing the request feedback messages in the RequestCycle? > Or should there be Page feedback messages that go over request? > But looking at the code this isn't being done now anyways. There can be, yes even now. Note that I changed this as Igor thought this was a useful use case. Before (yesterday) I cleaned up everything that was not a session bound message. I thought you agreed, but I'd be more than happy to revert that, as I feel more comfortable cleanup up aggressively and telling people to just use session bound messages if they want them to be carried over (or implement their own cleanup strategy, which is also easy). Look, I'm getting a bit tired of tweaking this all the time. Let me state what the options are: 1) The initial way of storing it in the component. We (at least some of us, I wasn't involved in this) decided this was too expensive in terms of storage. 2) The old way of storing it in in the page. I'm very much against this as it doesn't allow people to set messages in the constructor (which I even though it myself somewhere), which imho is a crazy limitation as storing in the page is an optimization over storing with the component in the first place. What I also didn't like about the way this was implemented was that messages were cleared up too late, and were serialized as part of the page state on every request, even if they already were rendered. 3) Storing it in a thread local temporarily (part of page). Implemented this and was about to commit it, and was backwards compatible with 2 with the exception that the cleanup was better and it worked at construction time. But then people were arguing against any use of thread locals and Jonathan argued he felt very strongly about the session being the right place for this. 4) The session. See the current situation. It's still an optimization over 1), which is conceptually the ideal situation. I think it works best (besides 1 that is), but here the big issue is when to clean up; do it aggressively (like I did) or more lenient (like it is now), trusting all messages to be rendered and thus cleaned up at some point. I'm for the agressive cleanup myself, but I thought more people (you, Igor, Martijn) were for the lenient approach. Maybe I misunderstood this. So... let's decide on this for once and for all. I'm leaning towards reverting back to 4) with aggressive cleanup, and I'll implement that unless we get some really good arguments or proposals here. Eelco
