Thanks again for the response, Sris response already answered my
question: it just can not be done with rpc; that's it.
On 28 Mai, 16:28, Jeff Chimene <jchim...@gmail.com> wrote:
> Hi Andreas:
>
> You can certainly send the two files to the server via GWTUpload. As Sri
Sorry Jeff, never wanted to send files to the server, I want to "send"
them to the client. What is send to the server is "data" in form of
documents in its abstract meaning (not concrete files).
> observed, the user must EXPLICITLY REQUEST THAT ACTION. Your browser app
> cannot do that on behalf of the user.
That's what answered my original question. Thanks a lot!
>
> You can receive "stuff" in the browser from the server. If it's a custom
> file structure, you'll have to open the app that handles that structure
> (like the browser opens Acrobat to handle PDF, or Office to handle Word Doc
> format) In order for this to work, you'll have to do a two-step process
> after sending the document to the server via GWTUpload
> Step 1: Receive the processing results from the server; which is the
> standard AJAX/GWTUpload response handling mechanism
> Step 2: Do the IFrame trick to actually request the document from the
> server. As you know, the server will send the appropriate headers to trigger
> the custom app to open the document.
I already heard about this proceeding but I clearly reject it. Doing
it this way requires temporary storage of the generated files or
session data or whatever AND two requests. It can be done in one
single request using GWT FormPanel. Data is send to the servlet in the
submission of the FormPanel in which the data is embedded as the value
of a TextArea for example. And after receiving the request in a
HttpServlet the "content-disposition"-magic thing can be done and
voila: the browser starts a download. Again, I just wanted to be sure
that it really can not be done with a rpc request.
Thank you all for the information.
>
> On Fri, May 28, 2010 at 12:31 AM, andreas
> <horst.andrea...@googlemail.com>wrote:
>
>
>
> > The goal is to download files to be stored by the user on disk. The
> > context application is a graphical editor which allows export of a
> > document in two formats. At the moment these are txt and ppt files.
> > They are generated separately so there is no problem with conflicting
> > MIME types or similar. By now I thought content type "application/
> > octet-stream" together with content-disposition "attachment" and a
> > file name would be enough.
>
> > Triggering download via IFrame URL or Window.open(URL, ...) works
> > fine, BUT how to pass information needed for server side file
> > generation. In particular I want to actually pass the whole document
> > currently edited in the browser application to the servlet that
> > generates to download file out of that document. One could surely use
> > parameters in the URL but I wonder if this way the passed information
> > is more vulnerable to interception than it would be when it was
> > located in the body of a request; like it is in the GWT rpc. That's
> > why I would have loved to use GWT rpc client side, pure HttpServlet on
> > the server side and finally forget about any sort of GWT CallBack back
> > in the browser but let the browser do a download based on response
> > headers. It is also very easy to get the parameters out of the request
> > again using GWT utility classes.
>
> > From what I also read in Sris response I quess I have to use FormPanel
> > submission or pass information using parameters in the URL which is
> > then opened via IFrame or Window.open(...).
>
> > Thank you very much for your response.
>
> > On 27 Mai, 16:28, Jeff Chimene <jchim...@gmail.com> wrote:
> > > Hi Andreas:
>
> > > It's quite possible to "... trigger a download via GWT..." You don't say
> > > what MIME type you're wanting. For example, I trigger a download of PDF
> > > document. GWT code cannot handle that, so the trigger is a GWT write to
> > an
> > > IFrame URL. The browser then renders the PDF in that frame.
>
> > > Perhaps you want to download HTML? If so, you have to stuff those results
> > > into some GWT widget. I usually do something like a MIME type of
> > text/json,
> > > which can be handled using a Javascript overlay type.
> > > { "status":"%S-Success", "cargo":"<div>stuff</div>"}
>
> > > which can handle situations like
> > > {"status":"%F-Fail","cargo":"<div>requested data not found</div>"}
>
> > > On Thu, May 27, 2010 at 7:17 AM, andreas <horst.andrea...@googlemail.com
> > >wrote:
>
> > > > Hi,
>
> > > > I'm trying to trigger a download via GWT rpc and/or GWT
> > > > RequestBuilder. The motivation of using rpc and/or RequestBuilder is
> > > > the ability to send data required for the on-the-fly generated
> > > > download files that way.
>
> > > > I already managed to modify the underlying request by using
> > > > RequestBuilder as return value of the rpc service method. The request
> > > > is routed to a HttpServlet implementing the doPost method. GWT utility
> > > > classes are used to obtain the RPCRequest instance and the given
> > > > parameters of the rpc service call successfully out of the
> > > > HttpRequest. After using the parameters and assembling the file on the
> > > > servlet in the doPost method the HttpResponse instance is used to
> > > > write that file. Headers 'content-disposition' and 'content-type' are
> > > > set accordingly to trigger a download in the browser.
>
> > > > However a download does not start. The response is accessible in the
> > > > RequestCallback instance assigned to the request. The point I do not
> > > > get about this is why the browser does not react to the content
> > > > disposition by downloading the file and instead passing the response
> > > > back to the ajax-world. I know that the rpc or request would fail
> > > > otherwise but that would be perfectly fine, since no response is
> > > > desired but a download.
>
> > > > Related posts:
>
> > > >http://groups.google.com/group/google-web-toolkit/browse_thread/threa.
> > ..
>
> > > >http://groups.google.com/group/google-web-toolkit/browse_thread/threa.
> > ..
>
> > > > I know that there are solutions with backposts and passing data via
> > > > parameters in the request url, but i would love to just stick to one
> > > > mechanism which is GWT rpc. I read a lot about that doing what i would
> > > > like to do is not possible but no one really said why. I especially
> > > > wonder why the browser does not do its thing since it is surely the
> > > > one that gets the response before the ajax code doesn't he?
>
> > > > I would like to hear about other solutions and if possible about why
> > > > exactly it is not possible to trigger download via GWT rpc. After all
> > > > escaping the GWT rpc mechanism on the server side works fine but on
> > > > the browser side not. Any ideas?
>
> > > > Greetings,
> > > > Andreas
>
> > > > --
> > > > 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-tool...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs
> > > > cr...@googlegroups.com><google-web-toolkit%2Bunsubs
> > cr...@googlegroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/google-web-toolkit?hl=en.
>
> > --
> > 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-tool...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs
> > cr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
