Page and compoenent level feedback are mixing together
I've searched for and read a number of threads on using multiple feedback panels on one page. I'm struggling with the same thing, but I haven't seen a response that is directly on point to my problem. We want to have a feedback component on our main page that most of the other pages in the application extend. This would be present to display any truly unexpected errors and the occasional feedback message related to things that happen in our menus or in our global search box (an invalid search query message for example). We also need to have a specific feedback panel for the forms that we use in our app. It's very easy to restrict what gets shown in that second feedback panel. We either add a ComponentFeedbackMessageFilter or use the convenience class, ComponentFeedbackPanel. The problem is that the page level feedback panel is catching the messages for the form level component as well. I'm not sure how to go about solving this. I'm reluctant to put some arbitrary filters on the page level feedback as it's intended to be a catch-all for things we don't expect (there's some AOP advice around our service tier calls that wrap exceptions and deliver them to this component). Any ideas? Matt -- View this message in context: http://www.nabble.com/Page-and-compoenent-level-feedback-are-mixing-together-tf4314782.html#a12285394 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page and compoenent level feedback are mixing together
you have to create your own custom feedback filter. this is simply how wicket feedback works. it is stored per page, and if you want to filter it you have to do it inside the panel. -igor On 8/22/07, Watter [EMAIL PROTECTED] wrote: I've searched for and read a number of threads on using multiple feedback panels on one page. I'm struggling with the same thing, but I haven't seen a response that is directly on point to my problem. We want to have a feedback component on our main page that most of the other pages in the application extend. This would be present to display any truly unexpected errors and the occasional feedback message related to things that happen in our menus or in our global search box (an invalid search query message for example). We also need to have a specific feedback panel for the forms that we use in our app. It's very easy to restrict what gets shown in that second feedback panel. We either add a ComponentFeedbackMessageFilter or use the convenience class, ComponentFeedbackPanel. The problem is that the page level feedback panel is catching the messages for the form level component as well. I'm not sure how to go about solving this. I'm reluctant to put some arbitrary filters on the page level feedback as it's intended to be a catch-all for things we don't expect (there's some AOP advice around our service tier calls that wrap exceptions and deliver them to this component). Any ideas? Matt -- View this message in context: http://www.nabble.com/Page-and-compoenent-level-feedback-are-mixing-together-tf4314782.html#a12285394 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page and compoenent level feedback are mixing together
On 8/22/07, Igor Vaynberg [EMAIL PROTECTED] wrote: you have to create your own custom feedback filter. this is simply how wicket feedback works. it is stored per page, and if you want to filter it you have to do it inside the panel. Still, using these filters is a bit clumsy imo. I can see Matt's case where you want to couple feedback panels to forms and let that print out the messages for only these forms, and whatever is left after that can be rendered by other feedback panels. In fact that would be a lot better than what we have now; how helpful is it anyway to have multiple feedbackpanels rendering out the same messages?. Only rendering messages for a form is possible using ContainerFeedbackMessageFilter, but the rest of the case... is not really possible in a simple fashion unless I'm overlooking something. Note that this case was actually what I tried to achieve 1.5 years ago or such with feedback boundries (though that had it's own problems, so I'm not arguing to get that back). Improving upon the current situation could work roughly like this: updateFeedback is done post order, and the implementations should mark feedbackmessages as accepted or something (IFeedbackMessageFilter would best be converted to an abstract class then so that we can guarantee marking the messages). When messages are marked, other components may choose to ignore them. If FeedbackPanel would work that way, we'd have Matt's behavior out-of-the-box, which imho is a lot better than the current way that feedbackmessages just print out any messages regarless whether they already were consumed by another feedback panel. WDYT? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page and compoenent level feedback are mixing together
On 8/22/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Improving upon the current situation could work roughly like this: updateFeedback is done post order, and the implementations should mark feedbackmessages as accepted or something (IFeedbackMessageFilter would best be converted to an abstract class then so that we can guarantee marking the messages). When messages are marked, other components may choose to ignore them. If FeedbackPanel would work that way, we'd have Matt's behavior out-of-the-box, which imho is a lot better than the current way that feedbackmessages just print out any messages regarless whether they already were consumed by another feedback panel. WDYT? what we need to do is collect usecases from our users. what you propose sounds great if you are doing component-hierarchy based filtering - but is this common. for example what about a usecase where there are two panels - one on top and one on bottom of a form showing the same messages - will we still support that? with your proposal sounds not, because panels would grab messages out of the set so a message can be shown at most one time by one panel. i would say ask our users for all these usecases, pick the most common ones but leave enough wiggle room to implement the uncommon ones. maybe really what we should do is not provide a feedbackpanel at all, but rather some callback that users can implement and build their own panels. -igor Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
