subject:"Re\: Reading placeholder parameters in mounted resources"

Re: Reading placeholder parameters in mounted resources

2013-07-23 Thread Francois Meillet

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  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

Re: Reading placeholder parameters in mounted resources

2013-07-23 Thread Cedric Gatay

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://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  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
>
>

Re: Reading placeholder parameters in mounted resources

2013-07-23 Thread Andrew Schetinin

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):

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();
   }

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  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://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  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
> >
> >
>

RE: Reading placeholder parameters in mounted resources

2013-07-23 Thread Paul Bors

For direction of creating a quick start see:
http://wicket.apache.org/start/quickstart.html


-Original Message-
From: Andrew Schetinin [mailto:ascheti...@gmail.com] 
Sent: Tuesday, July 23, 2013 3:58 PM
To: users@wicket.apache.org
Subject: Re: Reading placeholder parameters in mounted resources

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):

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();
   }

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  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  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
> >
> >
>


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Reading placeholder parameters in mounted resources

2013-07-23 Thread Martin Grigorov

Hi,


On Tue, Jul 23, 2013 at 10:57 PM, Andrew Schetinin 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  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://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  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. Therefo

Re: Reading placeholder parameters in mounted resources

2013-07-24 Thread Andrew Schetinin

Hi Martin,

Thank you for the advise with attributes.getPageParameters()
.get("id") - I did not know about it.

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

Now, that's not quite correct - when I create a resource reference (in
order to associate it with Image or get the resource URL). every time
Wicket calls to ResourceReference#getResource() in attempt to receive an
instance of the resource.
The stack trace looks like (Wicket 6.9):

MediaStorageResourceReference.getResource() line: 149
==>> ResourceMapper.addCachingDecoration(Url, PageParameters) line: 218
==>> ResourceMapper.mapHandler(IRequestHandler) line: 199
==>> SystemMapper(CompoundRequestMapper).mapHandler(IRequestHandler) line:
215
==>> RequestCycle.mapUrlFor(IRequestHandler) line: 429
==>> RequestCycle.urlFor(IRequestHandler) line: 529
==>> RequestCycle.urlFor(ResourceReference, PageParameters) line: 492
FileActionPropertiesPanel(Component).urlFor(ResourceReference,
PageParameters) line: 3407
MediaStorageResourceReference.urlForMediaFile(Component, long, String)
line: 107
FileActionPropertiesPanel.(String, List,
ThumbnailSize, int) line: 49

I highlighted here the Wicket code - this is how it arrives to the resource
instantiation. The logic there is quite obvious and straight-forward, and I
did not see any reasonable way to avoid that instantiation, even though I
don't need it at all - it's waste of computational time and resources :-)

Note that this getResource() call happens in the context of an absolutely
irrelevant request - I cannot even construct a correct resource (even if I
would wish to do so), because all request parameters belong to the
currently created panel, and not to the resource.

IMHO it is a design flaw, and I've seen earlier usergroup discussions on it.

So, because of the above, I need to keep the logic of extracting the ID
parameter, and that validation of the request path, in order to silently
prevent unnecessary instantiation of the resource.

Regards,

Andrew

On Wed, Jul 24, 2013 at 9:55 AM, Martin Grigorov wrote:

>
>
> 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.

--
Andrew Schetinin

Re: Reading placeholder parameters in mounted resources

2013-07-24 Thread Martin Grigorov

On Wed, Jul 24, 2013 at 11:31 AM, Andrew Schetinin wrote:

> Hi Martin,
>
> Thank you for the advise with attributes.getPageParameters()
> .get("id") - I did not know about it.
>
> You wrote:
> *Wicket won't call MediaStorageResourceReference#*
> *getResource() if the
> request url doesn't match the mount path.*
>
> Now, that's not quite correct - when I create a resource reference (in
> order to associate it with Image or get the resource URL). every time
> Wicket calls to ResourceReference#getResource() in attempt to receive an
> instance of the resource.
> The stack trace looks like (Wicket 6.9):
>
> MediaStorageResourceReference.getResource() line: 149
> ==>> ResourceMapper.addCachingDecoration(Url, PageParameters) line: 218
> ==>> ResourceMapper.mapHandler(IRequestHandler) line: 199
> ==>> SystemMapper(CompoundRequestMapper).mapHandler(IRequestHandler) line:
> 215
> ==>> RequestCycle.mapUrlFor(IRequestHandler) line: 429
> ==>> RequestCycle.urlFor(IRequestHandler) line: 529
> ==>> RequestCycle.urlFor(ResourceReference, PageParameters) line: 492
> FileActionPropertiesPanel(Component).urlFor(ResourceReference,
> PageParameters) line: 3407
> MediaStorageResourceReference.urlForMediaFile(Component, long, String)
> line: 107
> FileActionPropertiesPanel.(String, List,
> ThumbnailSize, int) line: 49
>
> I highlighted here the Wicket code - this is how it arrives to the resource
> instantiation. The logic there is quite obvious and straight-forward, and I
> did not see any reasonable way to avoid that instantiation, even though I
> don't need it at all - it's waste of computational time and resources :-)
>
> Note that this getResource() call happens in the context of an absolutely
> irrelevant request - I cannot even construct a correct resource (even if I
> would wish to do so), because all request parameters belong to the
> currently created panel, and not to the resource.
>

You can return an "empty" resource, i.e. a resource without any state.
Move your logic for reading the request parameters in
IResource#respond(Attributes) or
AbstractResource#newResourceResponse(Attributes).


>
> IMHO it is a design flaw, and I've seen earlier usergroup discussions on
> it.
>
> So, because of the above, I need to keep the logic of extracting the ID
> parameter, and that validation of the request path, in order to silently
> prevent unnecessary instantiation of the resource.


> Regards,
>
> Andrew
>
>
> On Wed, Jul 24, 2013 at 9:55 AM, Martin Grigorov  >wrote:
>
> >
> >
> > 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.
>
>
>
>
> --
> Andrew Schetinin
>

Re: Reading placeholder parameters in mounted resources

Re: Reading placeholder parameters in mounted resources

Re: Reading placeholder parameters in mounted resources

RE: Reading placeholder parameters in mounted resources

Re: Reading placeholder parameters in mounted resources

Re: Reading placeholder parameters in mounted resources

Re: Reading placeholder parameters in mounted resources

7 matches

Site Navigation

Mail list logo

Footer information