[Seaside] Setting HTTP Headers

[Ramon Leon]

> On Sep 22, 2007, at 11:55 PM, "Ramon Leon" <ramon.leon at allresnet.com>
> 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