Oh, okay. I really like that. It's a lot more control then we have now
and a lot more intuitive.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
infor
btw, it's a total hack and an ugly cast, but we should be able to
support backwards compatibility with the current Form(... IFeedback)
constructor by simply adding the form to the feedback.
/**
*
* @deprecated ...
*/
public Form(String id, ..., IFeedback feedback)
{
...
((AbstractFeed
in AbstractFeedback!
Original Message ----
Subject: Re: [Wicket-user] Feedback Refactor Idea
Date: Sun, 31 Jul 2005 00:25:26 -0700
From: Jonathan Locke <[EMAIL PROTECTED]>
To: wicket-user@lists.sourceforge.net
References: <[EMAIL PROTECTED]>
<[EMAIL PROTE
but not its children. so maybe it's just this until we find a need
for recursion control:
public void add(Component component, boolean recurse)
{
}
crap. it's getting late. i meant this of course:
public void add(Component component) { }
and if component instanceof Container
no. i failed to convey something important. the location of the
feedback component and the component(s) it collects messages from are
completely independent. it doesn't matter where either one is located.
looks like this:
public AbstractFeedback
{
...
public void add(Component comp
Yea, I like that too. How do we deal with multiple forms, each with a
panel just before it in the tree? Do we just require that you put the
panel inside each form in that case? I'm fine with that, unless it
could break (X)HTML compliance or layouts for some people.
On 7/30/05, Jonathan Locke <[EMA
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
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
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
> >through. Look at my ipageablecomponent patch, in my
> ipageablecomponent
> >I need to have getpage() which really shouldn't be there.
> >
> >Igor
> >
> >
> >
> >
> >
> >>-Original Message-----
> >>From: [EMAI
[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Saturday, July 30, 2005 10:30 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Feedback Refactor Idea
sorry, but yuck. what members would IComponent have? if it
has more than one or two members, it will break in a matter
-Original Message-
> >>From: [EMAIL PROTECTED]
> >>[mailto:[EMAIL PROTECTED] On Behalf
> Of Jonathan
> >>Locke
> >>Sent: Saturday, July 30, 2005 10:03 AM
> >>To: wicket-user@lists.sourceforge.net
> >>Subject: Re: [Wicket-user
L PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Jonathan Locke
> Sent: Saturday, July 30, 2005 10:30 AM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] Feedback Refactor Idea
>
>
> sorry, but yuck. what members would IComponent have? if it
> has
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Saturday, July 30, 2005 10:02 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Feedback Refactor Idea
no. what's in this "IComponent"? nothing of use. we only need this:
public
om: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Saturday, July 30, 2005 10:03 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Feedback Refactor Idea
Jonathan Locke wrote:
i think you're missing the point.
formcomponents should not
: [Wicket-user] Feedback Refactor Idea
no. what's in this "IComponent"? nothing of use. we only need this:
public interface IFeedback
{
public void updateFeedback()
}
the rest is pure and simple OO programming!
Igor Vaynberg wrote:
And I still have to cast Ifeedback to Compon
5 10:02 AM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] Feedback Refactor Idea
>
>
> no. what's in this "IComponent"? nothing of use. we only need this:
>
> public interface IFeedback
> {
> public void updateFeedback()
>
to look for the label's model.
Igor
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Jonathan Locke
> Sent: Saturday, July 30, 2005 10:03 AM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-us
Jonathan Locke wrote:
i think you're missing the point.
formcomponents should not possess feedbacks because formcomponents can
be wired to more
than one feedback component. so the relationship needs to be the
other way around. it's also
important that formcomponents never know anything a
no. what's in this "IComponent"? nothing of use. we only need this:
public interface IFeedback
{
public void updateFeedback()
}
the rest is pure and simple OO programming!
Igor Vaynberg wrote:
And I still have to cast Ifeedback to Component in order to
retrieve the model used for the l
i think you're missing the point.
formcomponents should not possess feedbacks because formcomponents can
be wired to more
than one feedback component. so the relationship needs to be the other
way around. it's also
important that formcomponents never know anything about the feedback
compone
> And I still have to cast Ifeedback to Component in order to
> retrieve the model used for the label.
Ok scractch this one, im searching only the component tree so the visitor
will return a component. Still we should have an Icomponent and have
Ifeedback extend Icomponent to make it clearer.
-Ig
What about generic validator messages - this is more important then the look
and feel of the label which I can achieve in a thousand different ways.
Using this model it is not possible to generically identify which Ifeedback
belongs to which FormComponent.
And what if there are more then one - ho
23 matches
Mail list logo
