Setting HTTP Headers
Locked
 
|
Is there any way for a component to set HTTP headers? I have a
component whose output must never be cached, so I want to the 'Cache- Control' header to force revalidation. I see where the the continuation creates the response, but it doesn't look like the response is ever accessible to the component. -- Ken Treis Miriam Technologies, Inc. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> Is there any way for a component to set HTTP headers? I have
> a component whose output must never be cached, so I want to > the 'Cache- Control' header to force revalidation. I see > where the the continuation creates the response, but it > doesn't look like the response is ever accessible to the component. > > -- > Ken Treis > Miriam Technologies, Inc. Have you actually checked your headers via firebug? Seaside headers are already set to No-cache. Ramon Leon http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I think that subclassing WASession and reimplementing
#returnResponse: may help. Michel. On Sep 23, 2007, at 8:55 AM, Ramon Leon wrote: >> Is there any way for a component to set HTTP headers? I have >> a component whose output must never be cached, so I want to >> the 'Cache- Control' header to force revalidation. I see >> where the the continuation creates the response, but it >> doesn't look like the response is ever accessible to the component. >> >> -- >> Ken Treis >> Miriam Technologies, Inc. > > Have you actually checked your headers via firebug? Seaside > headers are > already set to No-cache. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ramon Leon-5
On Sep 22, 2007, at 11:55 PM, "Ramon Leon" <[hidden email]>
wrote: > Have you actually checked your headers via firebug? Seaside headers > are > already set to No-cache. I hadn't seen that, thanks for pointing it out. In this case, though, I actually need Firefox to re-issue the GET when the back button is pushed. In my Rails app, I could set cache-control to "no-cache, no- store, must-revalidate" and that did the trick. I'm still working on adjusting my old way of thinking, since Seaside does so many of these things differently. Maybe there's a better way of approaching this problem. I'm working on a call center application, where the first component (after login) presents a menu. One of the menu choices, labeled "new call", starts a task that walks the operator through the process of taking information from the caller. Elsewhere, the app shows a report of how many calls are currently in progress. So when the operator pushes "new call", I need to register their status with a global "off hook" registry, and when they cancel or finish the task, I need to unregister them. So far so good, but a problem arises when they press "new call" and then use the back button to bail out. Now I have a registered off-hook operator who really isn't off-hook. If I could force a refresh when they come back to the menu, I could chide them when I notice that they're still registered as off-hook. But maybe there's a better way to solve this. I have toyed with the idea of keeping the off-hook boolean in an inst var of the session, and sweeping allInstances in order to count the off-hook ones. Or I could keep all logged-in sessions in a weak collection and scanning them that way. These would work, but I was hoping to find something a little less global. -- Ken Treis Miriam Technologies, Inc. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I'm not sure to understand enough what you're trying to do but the "global"
seems to smell not good. I suggest to question why do you need that global in first place and while questioning that evaluate using some instVar in the task itself to store that state or, if unrelated, put that state in a task that is parent of that task. I have a main task that looks like: UseOfSystemTask>>go [self login. self hasLogin] whileFalse. self useSystem UseOfSystemTask>>useSystem self call: MainSystemComponent new Inside MainSystemComponent you can also have N tasks which may map N of the worflows of the call center your system implements If you have some kind of odb of whatever persistent choice, then the backbutton should not be a problem if you make the renderContentOn: to render in the canvas fresh data like: WhateverComponent>>renderContentOn: html html render: self freshData Where #freshData collects fresh objects from wherever they are. That style ensures no need to do manual updates (unless the data is time critical or updated by others in that case some ajax can help) This way I don't see a need of any global cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Ken Treis > Enviado el: Lunes, 24 de Septiembre de 2007 01:45 > Para: Seaside - general discussion > CC: Seaside - general discussion > Asunto: Re: [Seaside] Setting HTTP Headers > > On Sep 22, 2007, at 11:55 PM, "Ramon Leon" <[hidden email]> > wrote: > > Have you actually checked your headers via firebug? > Seaside headers > > are already set to No-cache. > > I hadn't seen that, thanks for pointing it out. In this case, > though, I actually need Firefox to re-issue the GET when the > back button is pushed. In my Rails app, I could set > cache-control to "no-cache, no- store, must-revalidate" and > that did the trick. > > I'm still working on adjusting my old way of thinking, since > Seaside does so many of these things differently. Maybe > there's a better way of approaching this problem. > > I'm working on a call center application, where the first > component (after login) presents a menu. One of the menu > choices, labeled "new call", starts a task that walks the > operator through the process of taking information from the > caller. Elsewhere, the app shows a report of how many calls > are currently in progress. > > So when the operator pushes "new call", I need to register > their status with a global "off hook" registry, and when they > cancel or finish the task, I need to unregister them. So far > so good, but a problem arises when they press "new call" and > then use the back button to bail out. Now I have a registered > off-hook operator who really isn't off-hook. > > If I could force a refresh when they come back to the menu, I > could chide them when I notice that they're still registered > as off-hook. > > But maybe there's a better way to solve this. I have toyed > with the idea of keeping the off-hook boolean in an inst var > of the session, and sweeping allInstances in order to count > the off-hook ones. Or I could keep all logged-in sessions in > a weak collection and scanning them that way. These would > work, but I was hoping to find something a little less global. > > -- > Ken Treis > Miriam Technologies, Inc. > _______________________________________________ > 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 |
|
|
In reply to this post by Ken Treis
> On Sep 22, 2007, at 11:55 PM, "Ramon Leon" <[hidden email]>
> wrote: > > Have you actually checked your headers via firebug? > Seaside headers > > are already set to No-cache. As Michel said, you can do what you want on your session object something like this returnResponse: aResponse (aResponse headers detect: [:each | each key = 'Cache-Control'] ifNone: [^super returnResponse: aResponse]) value: 'no-cache, no-store, must-revalidate'. ^super returnResponse: aResponse The headers are stored in an OrderedCollection because headers are typically added rather than modified so there isn't a simple #headerAt: only a #headerAt:put > I hadn't seen that, thanks for pointing it out. In this case, > though, I actually need Firefox to re-issue the GET when the > back button is pushed. In my Rails app, I could set > cache-control to "no-cache, no- store, must-revalidate" and > that did the trick. > > I'm still working on adjusting my old way of thinking, since > Seaside does so many of these things differently. Maybe > there's a better way of approaching this problem. That's something we all go through. > I'm working on a call center application, where the first > component (after login) presents a menu. One of the menu > choices, labeled "new call", starts a task that walks the > operator through the process of taking information from the > caller. Elsewhere, the app shows a report of how many calls > are currently in progress. > > So when the operator pushes "new call", I need to register > their status with a global "off hook" registry, and when they > cancel or finish the task, I need to unregister them. So far > so good, but a problem arises when they press "new call" and > then use the back button to bail out. Now I have a registered > off-hook operator who really isn't off-hook. Where do they go back to? Could that page have an Ajax request on page load that ensures they're logged out? That was even when they hit their local cached version of the page, that callback would fire. Just a thought. > If I could force a refresh when they come back to the menu, I > could chide them when I notice that they're still registered > as off-hook. > > But maybe there's a better way to solve this. I have toyed > with the idea of keeping the off-hook boolean in an inst var > of the session, and sweeping allInstances in order to count > the off-hook ones. Or I could keep all logged-in sessions in > a weak collection and scanning them that way. These would > work, but I was hoping to find something a little less global. > > -- > Ken Treis > Miriam Technologies, Inc. I'm sure if you try a few things you'll come up with a solution that works without modifying the headers, though you certainly can if you like. Ramon Leon http://onsmalltalk.com _______________________________________________ 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 |