On Wed, Jul 24, 2013 at 11:31 AM, Andrew Schetinin <ascheti...@gmail.com>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.<init>(String, List<FileActionProperty>,
> 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 <mgrigo...@apache.org
> >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
>
