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] > >
