actually, i think it would be better to have a base class for feedback
components that
implements the recursive message gathering and which can be given a
Class at which to
stop. it could also include a filter method to allow the feedback to
filter components
in terms of which components get included in the message gathering and
also in terms
of which components are recursed into. so it would be something like:
public class AbstractFeedback implements IFeedback
{
final Class feedbackBoundary;
public AbstractFeedback(String id)
{
super(id);
this.feedbackBoundary = null;
}
public AbstractFeedback(String id, Class feedbackBoundary)
{
super(id);
this.feedbackBoundary = feedbackBoundary;
}
protected boolean recurseInto(Component component)
{
return feedbackBoundary == null ||
feedbackBoundary.isInstance(component);
}
protected boolean includeMessagesFrom(Component component)
{
return true;
}
}
public class FeedbackPanel extends AbstractFeedback
{
...
}
public class FeedbackLabel extends AbstractFeedback
{
...
}
public class MyPage
{
public MyPage()
{
// Add feedback panel for page that does not include messages
from the embedded form
add(new FeedbackPanel("feedback", Form.class));
}
}
Phil Kulak wrote:
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Ìk
_______________________________________________
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_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
