You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Maarten Billemont (JIRA)" <ji...@apache.org> on 2011/09/10 14:21:08 UTC

[jira] [Created] (WICKET-4039) Make Component#urlFor non-final

Make Component#urlFor non-final
-------------------------------

                 Key: WICKET-4039
                 URL: https://issues.apache.org/jira/browse/WICKET-4039
             Project: Wicket
          Issue Type: Improvement
            Reporter: Maarten Billemont


My use case is that I want to add an anchor to the URL generated for my Page, each time.  its urlFor would be an excellent place to do this, unfortunately it is final.  Which, to me, makes no sense whatsoever, because there's no point to its existence with it being final.  It doesn't use the instance's state, it just delegates to other static methods.  So why does Component#urlFor exist if it's not to give the developer an opportunity to intervene and inject custom behavior?

I hereby propose the urlFor methods become non-final.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (WICKET-4039) Make Component#urlFor non-final

Posted by "Pedro Santos (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102093#comment-13102093 ] 

Pedro Santos commented on WICKET-4039:
--------------------------------------

Componet#urlFor, getResponse, getRequest, etc, are only an facade API. The framework doesn't even use it everywhere, so open it for extensions can lead some inconsistencies.
Even if you want to implement the URL logic per component inside its class, would make more sense to provide a custom request mapper testing components for some interface like IKnowMyUrl.

> Make Component#urlFor non-final
> -------------------------------
>
>                 Key: WICKET-4039
>                 URL: https://issues.apache.org/jira/browse/WICKET-4039
>             Project: Wicket
>          Issue Type: Improvement
>            Reporter: Maarten Billemont
>
> My use case is that I want to add an anchor to the URL generated for my Page, each time.  its urlFor would be an excellent place to do this, unfortunately it is final.  Which, to me, makes no sense whatsoever, because there's no point to its existence with it being final.  It doesn't use the instance's state, it just delegates to other static methods.  So why does Component#urlFor exist if it's not to give the developer an opportunity to intervene and inject custom behavior?
> I hereby propose the urlFor methods become non-final.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Resolved] (WICKET-4039) Make Component#urlFor non-final

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-4039.
-----------------------------------

    Resolution: Invalid
      Assignee: Igor Vaynberg

Component#urlFor() is a convenience method and that is why it is final. it is easier to say { urlFor(ILinkListener.INTERFACE); } then { RequestCycle.get().urlFor(this, ILinkListener.INTERFACE); } it is also more convenient for noobs because IDEs will autocomplete available methods, but not something defined in another class.

for your particular requirement see Link#setAnchor()

> Make Component#urlFor non-final
> -------------------------------
>
>                 Key: WICKET-4039
>                 URL: https://issues.apache.org/jira/browse/WICKET-4039
>             Project: Wicket
>          Issue Type: Improvement
>            Reporter: Maarten Billemont
>            Assignee: Igor Vaynberg
>
> My use case is that I want to add an anchor to the URL generated for my Page, each time.  its urlFor would be an excellent place to do this, unfortunately it is final.  Which, to me, makes no sense whatsoever, because there's no point to its existence with it being final.  It doesn't use the instance's state, it just delegates to other static methods.  So why does Component#urlFor exist if it's not to give the developer an opportunity to intervene and inject custom behavior?
> I hereby propose the urlFor methods become non-final.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (WICKET-4039) Make Component#urlFor non-final

Posted by "Maarten Billemont (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102125#comment-13102125 ] 

Maarten Billemont commented on WICKET-4039:
-------------------------------------------

Whatever is decided in the end; it should involve consistency.  Either wicket should delegate via Component#urlFor whenever a relevant URL is needed; or those methods should be removed completely.

Right now it's just both inconsistent and useless.

> Make Component#urlFor non-final
> -------------------------------
>
>                 Key: WICKET-4039
>                 URL: https://issues.apache.org/jira/browse/WICKET-4039
>             Project: Wicket
>          Issue Type: Improvement
>            Reporter: Maarten Billemont
>
> My use case is that I want to add an anchor to the URL generated for my Page, each time.  its urlFor would be an excellent place to do this, unfortunately it is final.  Which, to me, makes no sense whatsoever, because there's no point to its existence with it being final.  It doesn't use the instance's state, it just delegates to other static methods.  So why does Component#urlFor exist if it's not to give the developer an opportunity to intervene and inject custom behavior?
> I hereby propose the urlFor methods become non-final.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira