Thanks, that worked!
I had though of something like that but the WebResource does not give you
access to a request cycle. I had forgotten that I can just call
RequestCycle.get().
Also I noticed the strangest thing while implementing it. Let's say I have
the following query string:
?order=1234&autoPrint=false
Whenever I get the PageParameters from the request cycle and try to retrieve
a parameter (say, "order") it gives me the memory reference for the string
instead of the string itself. For example it gives me
"[Ljava.lang.String;@1b4d41e" instead of "1234".
The same thing happens if I call
requestCycle.getRequest().getParameterMap().get("order")
But if I call requestCycle.getRequest().getParameter("order") it works fine.
It's not really a big problem because I can just call the method that works,
but, out of curiosity, any idea why this happens?
Denis Souza
-----Original Message-----
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Sent: terça-feira, 14 de setembro de 2010 14:22
To: users@wicket.apache.org
Subject: Re: Safe URL for a dynamic resource
you can read the parameters off the url yourself,
requestcycle.getrequest()...
-igor
On Tue, Sep 14, 2010 at 10:08 AM, Denis Souza <denis.so...@gmail.com> wrote:
> Hi,
>
>
>
> I'm trying to display a PDF file inside an IFRAME. To do that, I need a
url
> to place on the IFRAME's "src" attribute.
> My idea is to create a shared resource and mount a url to it so I can
> reference it easily. Since the PDF file is generated on-the-fly, I can
also
> pass a parameter through this url to determine the file's contents.
>
> However, I'm concerned about how safe it would be to do this. To add the
> shared resource I have to produce a single WebResource object. This would
be
> fine if the call to getResourceStream would also pass along the parameters
> that have been set, but the parameters are retrieved though a call to
> getParameters. That means that the setParameters method must be called by
> Wicket sometime before the call to getResourceStream is made.
>
>
>
> My question is: How can I be sure that multiple simultaneous requests
won't
> have concurrency problems in this scenario?
>
> Could there be a better way to do this?
>
>
>
> Thanks in advance,
>
> Denis Souza
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
