[Seaside] Setting HTTP Headers

Sebastian Sastre ssastre at seaswork.com
Mon Sep 24 13:53:43 UTC 2007


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: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] 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" <ramon.leon at allresnet.com>
> 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
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



More information about the seaside mailing list