Alright - thanks. Again, right now it just uses a hard coded string,
which works. However, if a user generates three different forms, and
then refreshes the three new windows (PDF file), the end result is
three copies of the last form that was generated and added to the
token.
Is there
Can we see how does your itext pdf look like? here is mine:
http://www.nabble.com/file/p17809870/DomesticApprovalS13371.pdf
On Apr 7, 10:50 pm, Carl Pritchett bogusggem...@gmail.com wrote:
Hi,
You'll have to work out a token generation scheme. If you find a nice
one, post it.
Sessions will
The simplest safest way I can think of is basically the same as other
people have already stated in this thread.
Using a token and storing data in the session means that the pdf data
is unique to the user (as long as the session is invalidated
properly).
- Send an RPC call to generate the pdf
you are not going to get RequestBuilder to be of much use to you in
this case either. That is for building an XMLHTTPRequest, the response
of which you will not be able to turn into a PDF.
your options are to open a new window and setting its url to the path
to your PDF generating servlet,
Thanks Carl! Your method worked fine. It's almost fully implemented,
but the only question I have that remains is the proper way to
generate tokens. I haven't ever had to generate them before - is
there an automatic way of generating unique tokens, or is generateToken
() a function I would
Hi,
You'll have to work out a token generation scheme. If you find a nice
one, post it.
Sessions will typically timeout (the timeout is app server dependent),
but I also added session.invalidate() on login to ensure that the
previous session is invalidated (e.g. two users usin the same
You can't send a PDF (or any other binary blob) to a GWT app over RPC.
Well, you can, but you can't do anything useful with it on the
client. You need to switch back to traditional servlets behind
traditional URLs. It's the same problem as serving images over RPC
and that's been discussed here
you are unlikely to get the pdf back from an RPC in any useful form.
The RPC mechanism is expecting a particular format, and manually
mucking about with the response object is going to upset that
expectation. Even if you did manage to get the bytes back via the
RPC's XHR, what would you
For itext just do a like to like a jsp page that will run the itext
gen. Thats how i do it and it works great.
On Apr 6, 11:55 am, Peter Ondruška peter.ondru...@gmail.com wrote:
I think you should not use GWT RPC servlet, just use normal servlet.
2009/4/6, Superman859
There is a PDF generation demo using a GWT entrypoint on the DynamicJasper
website (a wrapper for Jasper, which I think still uses iText deep inside).
http://dynamicjasper.sourceforge.net/
Anyway you can look at the relevant servlet code there, and the hand-off
from the GWT run report button.
Thanks for all the responses. I had (and still do) little
understanding of responses and requests as I rarely work directly with
them. However, I now see that GWT-RPC is not the way to go. From
what I've read and what I saw using Firebug, GWT-RPC sets up the
response variable for it's own
11 matches
Mail list logo
