[Seaside] [3.0] WAFileHandler not dealing with full paths?
Boris Popov, DeepCove Labs (YVR)
boris at deepcovelabs.com
Thu Mar 11 07:55:41 UTC 2010
Anything more than just the next token from the consumer would be an improvement. In fact, sure, why not pass the whole context with part of the path already consumed to find the library class, then the library can consume the rest.
-Boris (via BlackBerry)
----- Original Message -----
From: seaside-bounces at lists.squeakfoundation.org <seaside-bounces at lists.squeakfoundation.org>
To: Seaside - general discussion <seaside at lists.squeakfoundation.org>
Sent: Wed Mar 10 22:05:57 2010
Subject: Re: [Seaside] [3.0] WAFileHandler not dealing with full paths?
2010/3/10 Boris Popov, DeepCove Labs (YVR) <boris at deepcovelabs.com>:
> Perhaps I'm missing some element to this, but right now I'm looking at the
> handling of URLs such as,
> and it looks like it's impossible to have my library class respond to a
> request for file whose path includes a directory. The problem is that as
> WAFileHandler (/handler) is consuming the path #('library' 'directory'
> 'style.css') , immediately after finding a proper libraryClass it asks it to
> serve the document and passes value of "consumer next" instead of "consumer
> upToEnd" or some such thing resulting in my library being asked to serve
> 'directory' not 'directory/style.css'. Is this plain broken or by design? In
> case you're curious, I'm collapsing a directory tree into a single library
> by storing resources using their full path which includes directories.
Just do be sure I'm understanding you correctly, you'd like
#documentAt:forContext: to take a collection of Strings instead a
OTOH we could just pass in the context and access the consumer from there.
seaside mailing list
seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside