[
https://issues.apache.org/jira/browse/WICKET-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg updated WICKET-1924:
----------------------------------
Fix Version/s: 1.5-M1
we will be reworking url handling from scratch in 1.5 irequesttarget will
probably go away altogether.
> IRequestCodingStrategy abstraction leaks; reduce dependencies on
> WebRequestCodingStrategy
> ------------------------------------------------------------------------------------------
>
> Key: WICKET-1924
> URL: https://issues.apache.org/jira/browse/WICKET-1924
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.4
> Environment: OS X 10.5, Java 1.5
> Reporter: Willis Blackburn
> Fix For: 1.5-M1
>
>
> I've been working on figuring out how to mount my CMS pages under a path, so
> that request to (say) /cms/path/to/some/file returns a representation of the
> CMS resource at /path/to/some/file. In the process I've been
> reading/learning about how IRequestCodingStrategy and
> IRequestTargetUrlEncodingStrategy work.
> While the IRequestCodingStrategy and IRequestTargetUrlEncodingStrategy
> apparently define the contract between the request cycle processor and the
> object responsible for decoding and encoding URLs, there are several places
> in which the code seems to assume that the IRequestCodingStrategy
> implementation is WebRequestCodingStrategy. It would be nice if the
> WebRequestCodingStrategy was more encapsulated.
> For example:
> 1. WicketFilter assumes that any URL that starts with
> WebRequestCodingStrategy.RESOURCES_PATH_PREFIX is a Wicket URL.
> 2. WicketFilter also implements special handling for the last-modified
> header if the URL starts with WebRequestCodingStrategy.RESOURCES_PATH_PREFIX.
> 3. AbstractRequestTargetUrlCodingStrategy throws an exception if a caller
> tries to mount to /resources (in other words,
> WebRequestCodingStrategy.RESOURCES_PATH_PREFIX, although it actually uses a
> string literal).
> 4. Although CryptedUrlWebRequestCodingStrategy delegates to any
> IRequestCodingStrategy implementation, the rebuildUrl and shortenUrl methods
> are optimzied for WebRequestCodingStrategy. (Maybe there could be a
> interface that provides hints to CryptedUrlWebRequestCodingStrategy on how to
> shorten/expand the URL instead.)
> 5. RequestParameters invokes a static method in WebRequestCodingStrategy.
> 6. All (?) of the IRequestTargetUrlCodingStrategy implementations make use
> of static members in WebRequestCodingStrategy and seem to be aware of how
> WebRequestCodingStrategy constructs URLs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
