flow
Locked
 
|
Hello!
I'm having trouble with page flow. At one point I need a component to issue a download of file and #answer back to the caller. I'm issuing a download using: self requestContext respond: [ :response | response contentType: 'application/pdf'; document: (StandardFileStream readOnlyFileFullyNamed: fileName ); attachmentWithFileName: fileName ]. After that, "self answer" doesn't seem to work. What can I do about it? -- Milan Mimica http://sparklet.sf.net _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi Milan,
The problem is that both #respond: causes the callback processing to immediately halt so a response can be returned. You can do other stuff in the #respond: block, which will of course happen before the response is returned. You can also respond separately:
------- self requestContext response
contentType: 'application/pdf'; document: (StandardFileStream readOnlyFileFullyNamed: fileName ); attachmentWithFileName: fileName. "some other stuff" self requestContext respond. ---------- However, if your #answer is in response to a #call: that won't work either, since that will cause the continuation to be invoked and control flow will return to the method that did the #call: (your response will still be configured, but the code after the #call: will be executed, possibly altering the response). In this case, you could possibly use #home on the calling component to remove its delegations, but I'd question why you were using #call:/#answer: at all.
If the #answer is in response to a #show: or is triggering an #onAnswer: block in an embedded component, it should work fine to #answer inside the #respond: block. Hope that's helpful.
Julian 2011/6/14 Milan Mimica <[hidden email]> Hello! _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Julian Fitzell wrote:
> but I'd question why you were using #call:/#answer: at all. > > If the #answer is in response to a #show: or is triggering an > #onAnswer: block in an embedded component, it should work fine to > #answer inside the #respond: block. Well, it's quite simple. I'm #call-ing a component which does a ticket reservation. After the user fills the form, in the callback of the OK button, I'm sending a PDF (the ticket) to the user and returning flow to the calling component. That's how I imagined it anyway. -- Milan Mimica http://sparklet.sf.net _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I think you can return a component or something with #answer: if I'm not mistaken. There's always WATask, which may fit your idea.
Otherwise, you may consider using announcements. Maybe do form authentication with ajax and return any errors, or even return the results via ajax. Just some ideas, RS > Date: Thu, 16 Jun 2011 17:50:08 +0200 > From: milan.mimica@gmail.com > To: seaside@lists.squeakfoundation.org > Subject: Re: [Seaside] flow > > Julian Fitzell wrote: > > but I'd question why you were using #call:/#answer: at all. > > > > If the #answer is in response to a #show: or is triggering an > > #onAnswer: block in an embedded component, it should work fine to > > #answer inside the #respond: block. > > Well, it's quite simple. I'm #call-ing a component which does a ticket > reservation. After the user fills the form, in the callback of the OK > button, I'm sending a PDF (the ticket) to the user and returning flow to > the calling component. That's how I imagined it anyway. > > -- > Milan Mimica > http://sparklet.sf.net > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by mmimica
On Thu, Jun 16, 2011 at 4:50 PM, Milan Mimica <[hidden email]> wrote:
But how can the user both download a file *and* see an HTML page displayed? You can only respond once to a request... Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Mayhaps embedding it? It would be easy enough for the user to download then.
RS From: [hidden email] Date: Thu, 16 Jun 2011 23:43:31 +0100 Subject: Re: [Seaside] flow To: [hidden email] On Thu, Jun 16, 2011 at 4:50 PM, Milan Mimica <milan.mimica@...> wrote:
But how can the user both download a file *and* see an HTML page displayed? You can only respond once to a request... Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Embed what? In the end you still have to return a response and you can either return an HTML response or a PDF response... you can't return both. If you return a PDF, there is no way for the user to proceed further down that branch of the control flow (unless you were generating a PDF with callback links inside it :) ). It is, effectively, a dead branch, so #answering after returning a PDF doesn't make sense to me.
I'm still struggling to understand the flow that Milan is envisioning... Julian On Thu, Jun 16, 2011 at 11:52 PM, Robert Sirois <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hehe yea. I was thinking the pdf could be embedded in whatever the response page is, that way you could preserve the navigation. Am I getting at what you're thinking Milan? Some sites open up new pages for printing things, too.
RS From: [hidden email] Date: Fri, 17 Jun 2011 08:46:07 +0100 Subject: Re: [Seaside] flow To: [hidden email] Embed what? In the end you still have to return a response and you can either return an HTML response or a PDF response... you can't return both. If you return a PDF, there is no way for the user to proceed further down that branch of the control flow (unless you were generating a PDF with callback links inside it :) ). It is, effectively, a dead branch, so #answering after returning a PDF doesn't make sense to me. I'm still struggling to understand the flow that Milan is envisioning... Julian On Thu, Jun 16, 2011 at 11:52 PM, Robert Sirois <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Right, so if you open a new window or embed inside on iframe or use JS to somehow fetch and embed the content, then that will work fine since a second request/response are involved. One callback returns the PDF and the other does the #answer.
Julian On Fri, Jun 17, 2011 at 2:32 PM, Robert Sirois <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
This sound similar to a setup I did, except in reverse: User uploads a file, has it validated and then the application proceeds.
I suspect what you could do is to provide a download button or link _and_ an 'ok' or 'next' or some button that will proceed with your application flow. Yes this presents 2 buttons, and allows the user to proceed w/o downloading the pdf, but you can solve that but checking to see if they clicked the download link before proceeding with the application flow. The key is that #answer doesnt return the pdf download response. Hopefully that makes sense? On Fri, Jun 17, 2011 at 7:04 AM, Julian Fitzell <[hidden email]> wrote:
Right, so if you open a new window or embed inside on iframe or use JS to somehow fetch and embed the content, then that will work fine since a second request/response are involved. One callback returns the PDF and the other does the #answer. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Julian Fitzell-2
Julian Fitzell wrote:
> But how can the user both download a file *and* see an HTML page > displayed? You can only respond once to a request... Yes, I came to the same conclusion. It's only HTTP. Some sites perform some delayed ajax to redirect the brower once the download has started, or similar. I made a separate "download" button. It will be fine. -- Milan Mimica http://sparklet.sf.net _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Jon Paynter-2
Jon Paynter wrote:
> This sound similar to a setup I did, except in reverse: User uploads > a file, has it validated and then the application proceeds. > > I suspect what you could do is to provide a download button or link > _and_ an 'ok' or 'next' or some button that will proceed with your > application flow. Yes this presents 2 buttons, and allows the user to > proceed w/o downloading the pdf, but you can solve that but checking > to see if they clicked the download link before proceeding with the > application flow. > > The key is that #answer doesnt return the pdf download response. > > Hopefully that makes sense? It does make sense :) Thanks for input everyone. -- Milan Mimica http://sparklet.sf.net _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by mmimica
Milan, Many sites simply use meta refresh to achieve the effect of triggering a file download once the next page opens up (and also include a link/button to trigger a manual download should anything happen that prevents the meta from performing as desired). Here's an example from CNET, <META HTTP-EQUIV="Refresh" CONTENT="0; URL=http://software-files-l.cnet.com/s/software/11/90/35/63/wrar401.exe?e=1308359520&h=f39cdec43bab91c125d8e78ca3685cf7&lop=link&ptype=1901&ontid=2250&siteId=4&edId=3&spi=944705fef3fce43686239204d08c7663&pid=11903563&psid=10007677&fileName=wrar401.exe"/> $('pdlManual').addEvent('click', function() { img_track('http://dw.com.com/redir?edId=3&siteId=4&oId=3001-2250_4-10007677&ontId=2250_4&lop=txt&mfgId=113677&merId=113677&pguid=KPsiAwoOYJQAAEmniYoAAAGP&ctype=dl_dlnow&cval=user_init&destUrl=http%3A%2F%2Fimg.com.com%2Fb.gif'); new IFrame({ src:'http://software-files-l.cnet.com/s/software/11/90/35/63/wrar401.exe?e=1308359520&h=f39cdec43bab91c125d8e78ca3685cf7&lop=link&ptype=1901&ontid=2250&siteId=4&edId=3&spi=944705fef3fce43686239204d08c7663&pid=11903563&psid=10007677&fileName=wrar401.exe', styles: { width:0, height:0, border:'0px solid #FFFFFF' } }).inject($('pdlManual'), 'after'); }); -Boris -----Original Message----- Julian Fitzell wrote: > But how can the user both download a file *and* see an HTML page > displayed? You can only respond once to a request... Yes, I came to the same conclusion. It's only HTTP. Some sites perform some delayed ajax to redirect the brower once the download has started, or similar. I made a separate "download" button. It will be fine. -- Milan Mimica _______________________________________________ seaside mailing list http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
2011/6/17 Boris Popov, DeepCove Labs <[hidden email]>:
> Milan, > > > > Many sites simply use meta refresh to achieve the effect of triggering a > file download once the next page opens up (and also include a link/button to > trigger a manual download should anything happen that prevents the meta from > performing as desired). Here's an example from CNET, I hate sites that do that. What's wrong with a simple download link? Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Um, to show you more ads after you clicked on the download button? Yea, pretty sure that's it, but that wasn't the point I was addressing. If someone has a requirement to do it this way, they can.
-Boris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Philippe Marschall Sent: Saturday, June 18, 2011 10:03 AM To: Seaside - general discussion Subject: Re: [Seaside] flow 2011/6/17 Boris Popov, DeepCove Labs <[hidden email]>: > Milan, > > > > Many sites simply use meta refresh to achieve the effect of triggering > a file download once the next page opens up (and also include a > link/button to trigger a manual download should anything happen that > prevents the meta from performing as desired). Here's an example from > CNET, I hate sites that do that. What's wrong with a simple download link? Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |