[
https://issues.apache.org/jira/browse/WICKET-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-2101.
-----------------------------------
Resolution: Fixed
Assignee: Igor Vaynberg
what do i propose? well...since it made it into the RC we cannot remove it. so
i have deprecated it and we will remove it in 1.5. i have added the accessor
you need so you can do whatever it is you need to. i did not change
bookmarkablepagelink, since pagelink is going away there is no sense to do that.
> PageLink is inherently non extendable
> -------------------------------------
>
> Key: WICKET-2101
> URL: https://issues.apache.org/jira/browse/WICKET-2101
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC2
> Reporter: Dominik Drzewiecki
> Assignee: Igor Vaynberg
> Fix For: 1.4-RC3
>
> Attachments: link.patch
>
>
> Due to the fact that there is no accessor provided for the private final
> IPageLink pageLink, there's no way of writing subclasses that would be aware
> of the pages they are linking to. My particular case is closely related to
> the annotation based authorization and an enhancement proposal
> http://issues.apache.org/jira/browse/WICKET-2089. Now, provided that this
> enhancement (that otherwise needs more look into) won't make it into
> wicket/wicket-auth-roles (though I am more than convinced that it should),
> and I would have to put the proposed IAuthorisationStrategy implementation
> outside core wicket, I would also have to write (copy&paste) my own PageLink
> that exposes its pageLink member in order to retrieve the page class it is
> referring to and substitute all occurernces of
> org.apache.wicket.markup.html.link.PageLink with it in my projects, so that
> my IAuthorisationStrategy implementation can retrieve the page class the the
> link is pointing to. Please note, that BokmarkablePageLink, which also is
> constructed with Page class *does* expose page class identity via public
> final Class<? extends Page> getPageClass().
> I suggest that for the sake of keeping the API clean and coherent the method
> with the same signature as in BookmarkablePageLink should be added to the
> PageLink.
> public Class<? extends Page> getPageClass()
> {
> return pageLink.getPageIdentity();
> }
> Another question arises - why BookmarkablePageLink is not a subclass of
> PageLink and why class resolution for those classes differs so much. Wouldn't
> it be easier to keep the class reference in the BookmarkablePageClass rather
> than its textual representation and skip all this mumbo-jumbo class
> resolution. But this is quite another story and OT for this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
