[Seaside] Computation has been terminated - error is back

[Avi Bryant]

On Mon, 13 Jan 2003, Derek Brans wrote:

> Back to square one.  Things I've changed: I've subclassed WASession to
> handle 'unknownRequest' and also 'longUniqueKey'.
> The latter might warrant some attention:
> longUniqueKey
> 	"ensure uniqueness even across sessions"
> 	^ response useCookies
> 		ifTrue: [sessionKey, '-', self uniqueKey]
> 		ifFalse: [self uniqueKey]
>
> This is the WASession implementation.  However, there's a bug in that
> code cause when using cookies I've found that sometimes sessionKey is
> nil.  So I subclassed it to check for sessionKey being nil.

Odd - sessionKey should never be nil.  Can you reliably reproduce a
situation where it is?

> Can you tell me more about how a request would accidentally get handled
> twice?  I subclassed WARequest but that was only to handle url parsing
> differently.

Have you looked at, eg, the 2.15 code at all?  It adds a new "section"
part to the url that might already do what you're trying for with
WARequest - urls are now

/seaside/appname/sectionKey/actionKey;sessionKey

sectionKey defaults to 'main', but you can set it with WASession>>section:
whenever you want, or the user might type in
/seaside/appname/someSectionKey .

You still want to override unknownRequest: to get at the sectionKey.  See
WAWikiSession for an example.

Avi