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
