> Hi, I apologize in advance, I am extremely new to HttpServelet and
> RequestBuilders, so if this is a dumb question, I apologize. I
> typically just work with RPC's, but I don't think this will work in
> this case.
>
> I have the user select a bunch of options from the website, then I hit
> publish, and it sends the data to the server (using serializable
> objects, not Strings) and on the server a PDF is generated, and I want
> to return the PDF. I can send the objects, make the PDF, but I can't
> return it using RPC's.
That's correct.
If you search the list, this has been discussed many times. You'll
probably want to post the raw data to the server, then enable a "get the
results" button after generating the PDF. But, I don't know the user
requirements.
I've also done the following: establish an invisible frame with a NULL
URL then on a certain state change in the main UI: 1) change that
frame's url to the generated PDF, and 2) make the frame visible.
> After googling a bunch, it seems I should be using a RequestBuilder
> with an HttpServlet on the Server side. However, it seems you really
> can't send much data with the request, just a single string. Am I
> supposed to encode all the data into one string and then decode it on
> the other side? That seems like a huge hassle, one I will have to re-
> do for every Servlet, compared to RPC's.
>
> For example, I am sending a bunch of SoftballGame objects. Each with
> their home team, away Team, time and which team is selected to win. I
> don't want to have to encode the team names, as well as the time and
> selection into a string, and then do that for all the games.
That's one solution. The other is to establish a server session,
incrementally accumulate each team's info, then publish it on demand.
> What's the proper way to attack this?
There is no "proper way". You just have to be aware that you can't
retrieve a PDF file like you would any other RPC response. If
implementing solutions to that limitation is what you mean by "proper"
(as opposed to accumulating the team data), then the "proper way" is to
use a GET to a URL that returns data encoded as an "application/pdf"
mime type. I prefer a GET to a POST, as my users might want to bookmark
the URL, and I will not send data that cannot be encoded in the URL.
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment