I would like to see the IFeedbackBoundary interface go away, replaced
with isFeedbackBoundary() in Component. That way you can just set up
boundaries as you see fit. I really don't like interfaces that have no
methods.
Eelco, how do you make a page-level FeedbackPanel?
On 7/30/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Thought about it a bit, and I think it is a good idea. I'm not sure
> whether we should loose IFeedbackBoundary too. We can just hardcode the
> boundaries (Form, Page) we need at the specific components
> (FeedbackPanel), but I kind of like the pattern of having a stopping
> interface instead. What do you think of this?
>
> It is important to me to be able to use this concept with (one of the)
> default FeedbackPanel(s) though. I have had the need to have a seperate
> 'page level' panel and a 'form level' panel in several occasions
> allready. But I can also see the need of having a global level panel
> (which is perfectly possible right now btw) too.
>
> Like stated before, I also think we should back any change up with a
> decent set of use cases, implemented in wicket-examples as a seperate
> examples. This to get the use cases clear, and document the usage right
> away.
>
> Do we open an RFE for this?
>
> Eelco
>
>
> Jonathan Locke wrote:
>
> >
> > at this point, it looks like it would make more sense to me to break
> > with compatibility and change IFeedback to something more like this:
> >
> > interface IFeedback
> > {
> > public void updateFeedback();
> > }
> >
> > then have the framework call updateFeedback() on each IFeedback
> > implementing component on the page at the appropriate time (probably
> > onBeginRequest(), but subject to implementation details).
> >
> > then we can implement any kind of feedback component that we want to.
> > igor can implement like this:
> >
> > public class FormComponentFeedbackLabel extends Label implements
> > IFeedback
> > {
> > FormComponent component;
> >
> > public FormComponentFeedbackLabel(FormComponent component)
> > {
> > this.component = component;
> > }
> >
> > public void updateFeedback()
> > {
> > // Set label look and feel based on any error in component
> > }
> > }
> >
> > FormComponentErrorIndicator would be similar, showing/hiding its
> > content on error. And FeedbackPanel and FormComponentFeedbackBorder
> > would do their recursive magic in update()
> >
> > so now every feedback component is "pull model" and updated at the
> > appropriate time by implementing updateFeedback(). best of all, the
> > component can do absolutely anything based on the state of any other
> > components passed in to whatever constructor the feedback component
> > has...
> >
> > doesn't this seem a whole lot simpler and more flexible?
> >
> > Jonathan Locke wrote:
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
