Hi,

On Tue, Jul 23, 2013 at 10:57 PM, Andrew Schetinin <ascheti...@gmail.com>wrote:

> Hi Cedric,
>
> I'm not sure what you mean by a quick start, but here you may find the
> piece of code I'm using:
>
> This is how the shared resource is initialized with the application:
>
> @Override
> protected void init() {
>         super.init();
>         mountResource( "/storage/${id}",
>                 new MediaStorageResourceReference() );
> }
>
> This is how a URL is constructed:
>
> final PageParameters params = new PageParameters();
> params.add( "id", "12345" );
> params.add( "thumb", "true" );
> params.add( "size", "25" );
> final CharSequence ret = component.urlFor( new
> MediaStorageResourceReference(), params );
> //  ./storage/12345?thumb=true&size=25
>
> And this is the code of the resource reference (the resource can do
> anything - it is irrelevant to the story):
>

It is relevant, actually.

IResource#respond() receives an argument of
type org.apache.wicket.request.resource.IResource.Attributes.
With attributes.getPageParameters().get("id") you can read the parsed path
parameter.


>
> public class MediaStorageResourceReference extends ResourceReference {
>     private static final Key key = new Key(
>             MediaStorageResourceReference.class.getName(),
>             "storage", Locale.ENGLISH, null, null );
>     public MediaStorageResourceReference() {
>         super( key );
>     }
>     @Override
>     public IResource getResource() {
>         final Request request = RequestCycle.get().getRequest();
>         // Wicket uses the same singleton instance also for detecting
>         // if the given resource can be cached by the server - we don't
> need that,
>         // and the only way to skip that test is to check the URL,
>         // because the check is done by Wicket during forUrl() call,
>         // within the context of a different request.
>         if( !request.getUrl().getPath().startsWith( "storage" ) ) {
>             logger.debug( "Fake resource request" );
>             return null;
>         }
>
>         final IRequestParameters params = request.getRequestParameters();
>
>         Long id = params.getParameterValue( "id" ).toOptionalLong();
>         if( id == null ) { // TODO: ask in Wicket forum why the ID is not
> extracted
>             // request.getUrl().getPath() = storage/72147598477361153
>             // fallback to extract the ID from path
>             if( request.getUrl().getPath().startsWith( URL_PATH_PREFIX ) )
> {
>                 final String s = request.getUrl().getPath().substring(
> URL_PATH_PREFIX.length() );
>                 try {
>                     id = new Long( s );
>                 } catch( final NumberFormatException e ) {
>                     logger.error( "Cannot extract ID from the path: {}",
> request.getUrl().getPath() );
>                 }
>             }
>             if( id == null ) {
>                 throw new AbortWithHttpErrorCodeException(
> HttpStatus.SC_NOT_FOUND );
>             }
>         }
>         .........
>         return new MyResource();
>

Since IRequestParameters knows nothing about path parameters, but just
normal request parameters (see HttpServletRequest#getParameters()) you can
move your logic for extracting the id parameter in the resource.

Wicket won't call MediaStorageResourceReference#getResource() if the
request url doesn't match the mount path.


>    }
>
> Note the workaround for retrieving the ID above - it is required because
> the list of parameters does not contain any "id" - only the optional
> arguments.
>
> Regards,
>
> Andrew
>
> --
> Andrew Schetinin
>
>
> On Tue, Jul 23, 2013 at 9:47 PM, Cedric Gatay <gata...@gmail.com> wrote:
>
> > Hi,
> > I think this is because you're mixing path parameters with query string
> > one. It could be a bug, could you provide a quickstart with this to help
> us
> > qualify and fix it if it is a bug.
> >
> > Regards,
> >
> > __
> > Cedric Gatay (@Cedric_Gatay <http://twitter.com/Cedric_Gatay>)
> > http://code-troopers.com | http://www.bloggure.info |
> > http://cedric.gatay.fr
> >
> >
> > On Tue, Jul 23, 2013 at 7:31 PM, Francois Meillet <
> > francois.meil...@gmail.com> wrote:
> >
> > > Try this pattern /storage/${id}/#{shape}
> > >
> > > Optional parameters are denoted by using a # instead of $
> > >
> > >
> > > François Meillet
> > > Formation Wicket - Développement Wicket
> > >
> > >
> > >
> > >
> > >
> > > Le 23 juil. 2013 à 19:14, Andrew Schetinin <ascheti...@gmail.com> a
> > écrit
> > > :
> > >
> > > > Hi,
> > > >
> > > > I have a shared resource mounted to a URL pattern "/storage/${id}"
> > > > So that the URL look like "/storage/12345"
> > > > and with optional additional parameters "/storage/12345?shape=xyz"
> > > >
> > > > It works fine when I create a new URL - the "id" parameter is
> correctly
> > > > encoded in the URL.
> > > >
> > > > But when I process the actual request, I only receive the optional
> > > > parameters like "shape", while "id" parameter is not present in
> > > > RequestParameters. Therefore I need to parse the URL string and
> extract
> > > the
> > > > ID parameters manually.
> > > >
> > > > The question is - why Wicket does not decode the parameters back?
> > > > Is it by design, or is it only a problem with shared resources?
> > > >
> > > > Regards,
> > > >
> > > > Andrew
> > > >
> > > > --
> > > > Andrew Schetinin
> > >
> > >
> >
>

Reply via email to