[ 
https://issues.apache.org/jira/browse/WICKET-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Funk updated WICKET-2265:
--------------------------------

    Attachment: patch-mf-2265.diff

sort of like this??

> Drop AbstractHeaderContributor and friends
> ------------------------------------------
>
>                 Key: WICKET-2265
>                 URL: https://issues.apache.org/jira/browse/WICKET-2265
>             Project: Wicket
>          Issue Type: Bug
>            Reporter: Martin Funk
>             Fix For: 1.5-M1
>
>         Attachments: patch-mf-2265.diff
>
>
> if anything, AbstractHeaderContributor and friends can go away. it is
> part a sub-framework that has grown a little out of control. They are
> just conveniences.
> -igor
> On Thu, May 7, 2009 at 3:32 AM, Martin Funk <[email protected]> wrote:
> Hi,
> as I'm poking IBehavior I came across AbstractBehavior and its descendent
> AbstractHeaderContributor
> Both claim to implement IHeaderContributor. Why is it this way?
> I poked around further and dropped the IHeaderContributor interface in
> AbstractBehavior which revealed that quite some Classes use the renderHead
> method of AbstractBehavior, but also quite some don't.
> Doubts bugged me to soon to come up with a complete patch for that, so
> instead I'm writing this e-mail now.
> So why is it this way? Shouldn't IHeaderContributor rather be droped out of
> AbstractBehavior and let all the other classes that need the renderHead
> descend from AbstractHeaderContributor, or HeaderContributor?
> Once at it I'd also change the housekeeping of the contributors in
> AbstractHeaderContributor, like
> protected abstract List<IHeaderContributor> etHeaderContributors();
> instead of:
> public abstract IHeaderContributor[] getHeaderContributors();
> what you think?
> Martin

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to