[Seaside] Computation has been terminated - error is back
Avi Bryant
seaside@lists.squeakfoundation.org
Mon, 13 Jan 2003 15:26:54 -0800 (PST)
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