[Seaside] Serving files with WAComancheAdapter

Wed Oct 27 16:12:19 UTC 2010

FWIW, as Johan pointed out, files can be served easily by creating a request
handler of type File Directory from the config page. I didn't find this
though, because the Seaside-FileSystem package is not included in the Seaside
3.0 One-Click Experience distribution. I evaluated

Gofer new
    squeaksource: 'MetacelloRepository';
    package: 'ConfigurationOfSeaside30';
    load.
(Smalltalk at: #ConfigurationOfSeaside30) load.

and it magically appeared.

Is there a reason why some packages are  not present in the One-Click
Experience? Should I shun the One-Click Experience and do manual
installations from now on?

TF

On Tue, Oct 26, 2010 at 12:20 PM, Tony Fleig <tony.fleig at gmail.com> wrote:

> My aim is not to improve performance or manage image memory but to improve
> ease of installation and maintenance during development. I want to avoid
> repeatedly editing large CSS files and installing and configuring Apache
> during development.
>
> When deployed, I would imagine that the static files would be served by an
> appropriately configured Apache server as this seems to be the recommended
> approach.
>
> That said, wouldn't it be possible for me to cache the files when they were
> accessed the first time and avoid the file I/O after that? It seems to me
> that the effect then would be image-resident files essentially equivalent to
> WAFileLibrary but without the need to pre-load the files, mangle the file
> names, change cross-file references, and destroy any directory hierarchy
> that might have existed.
>
> TF
>
>
> On Tue, Oct 26, 2010 at 12:05 PM, John McKeon <p3anoman at gmail.com> wrote:
>
>> Please correct me if I am wrong, but this still serves the files through
>> the image, only now you are imposing the overhead of first reading the file
>> from the hard drive. This will slow things down, not speed them up, but
>> perhaps your aim is to conserve RAM used by the image? (But of course,
>> loading the files into the image will temporarily increase in-memory image
>> size, and since every request will create load its own set of files from the
>> hard drive, this could drive memory usage way up depending on how many
>> requests are being served.
>> Am I interpreting this correctly?
>>
>> John
>>
>> On Tue, Oct 26, 2010 at 1:16 PM, Tony Fleig <tony.fleig at gmail.com> wrote:
>>
>>> I want to serve CSS and Javascript files from an on-disk directory (i.e.
>>> not using WAFileLibrary) and also not using Apache.
>>>
>>> I have JQuery CSS files that reference a large number of image files from
>>> an images subdirectory. When these files are imported into a WAFileLibrary,
>>> the image filenames are changed and of course there are no subdirectories.
>>> Changing the original css file to accommodate this is not practical as I
>>> expect to receive new ones periodically and then would have to do it all
>>> over again.
>>>
>>> I am attracted by the easy deployment of Seaside apps when Apache is not
>>> involved and for the few files involved it doesn't seem to me that Apache is
>>> warranted, especially during development of the site.
>>>
>>> I could find no information on the right way to do this, so I subclassed
>>> WAServerAdaptor as shown below.
>>>
>>> With these modifications, If the URL received from the browser's path
>>> begins with /static, then files are served from a specified directory.
>>> Otherwise, the request is passed on (eventually) to WADispatcher as normal.
>>>
>>> This works for me, but I have no idea as to whether there is an easier or
>>> better way or if there is a feature to allow this that I just did not find.
>>>
>>> I am coming back to Smalltalk after many years and I am definitely a bit
>>> rusty, so any criticism of the code will also be greatly appreciated.
>>>
>>> Regards,
>>> TF
>>>
>>>
>>>  'From Pharo1.1 of 17 July 2010 [Latest update: #11411] on 26 October
>>> 2010 at 10:08:40 am'!
>>> WAComancheAdaptor subclass: #TFComancheAdaptor
>>> instanceVariableNames: 'staticDirectory staticPathPart'
>>> classVariableNames: ''
>>> poolDictionaries: ''
>>> category: 'TFStuff'!
>>>
>>> !TFComancheAdaptor methodsFor: 'as yet unclassified' stamp: 'TF
>>> 10/26/2010 08:58'!
>>> defaultStaticDirectory
>>> ^ FileDirectory default pathName! !
>>>
>>> !TFComancheAdaptor methodsFor: 'as yet unclassified' stamp: 'TF
>>> 10/26/2010 08:59'!
>>> defaultStaticPathPart
>>>
>>> ^ 'static'! !
>>>
>>> !TFComancheAdaptor methodsFor: 'as yet unclassified' stamp: 'TF
>>> 10/26/2010 09:55'!
>>> process: aNativeRequest
>>> "Serve static files from a specified directory if the URL path begins
>>> with a specified name.
>>>  The default staticDirectory is the current directory (nominally the
>>> Seaside resources directory)
>>> and the default static path part is 'static'. Thus, if the client
>>> requests
>>> 'http://localhost:8080/static/css/xyz.css' and the Seaside resources
>>> directory is
>>> '/home/user1/Seaside.app/Contents/Resources', the file returned will be
>>> '/home/user1/Seaside.app/Contents/Resources/static/css/xyz.css'.
>>>  Requests whose path does not begin with the static path part are
>>> unaffected, i.e. they are
>>> processed by the WAComancheAdapter as normal."
>>>
>>> | context pathParts fullFilePath method response |
>>> pathParts := aNativeRequest pathParts.
>>> pathParts size > 1 ifTrue: [
>>> (pathParts at: 1) = self staticPathPart ifTrue: [
>>> method := aNativeRequest method.
>>> (#(#GET #POST) includes: method) ifFalse: [^nil].
>>> fullFilePath := self staticDirectory,aNativeRequest url.
>>> (FileStream isAFileNamed: fullFilePath) ifFalse: [^nil].
>>> ^HttpResponse
>>> fromStream: (StandardFileStream readOnlyFileNamed: fullFilePath).
>>> ]
>>> ] .
>>>
>>> ^ self processResponse: (super process: aNativeRequest)
>>> ! !
>>>
>>> !TFComancheAdaptor methodsFor: 'as yet unclassified' stamp: 'TF
>>> 10/26/2010 09:54'!
>>> processResponse: aResponse
>>>
>>> "Ensures that we get the HttpAdaptor's standard notFound error
>>> return, rather than the one line of text/plain that is returned by
>>> WADispatcher."
>>>  aResponse status = #notFound
>>> ifTrue: [ ^nil ]
>>> ifFalse: [^aResponse]
>>> ! !
>>>
>>> !TFComancheAdaptor methodsFor: 'as yet unclassified' stamp: 'TF
>>> 10/26/2010 08:52'!
>>> staticDirectory
>>>
>>> staticDirectory isNil ifTrue: [ staticDirectory := self
>>> defaultStaticDirectory ].
>>> ^ staticDirectory! !
>>>
>>> !TFComancheAdaptor methodsFor: 'as yet unclassified' stamp: 'TF
>>> 10/26/2010 08:57'!
>>> staticPathPart
>>>  staticPathPart isNil ifTrue: [ staticPathPart := self
>>> defaultStaticPathPart ].
>>> ^ staticPathPart! !
>>>
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>>
>>
>>
>> --
>> http://john-mckeon.us
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
>
> --
> P1 SYSTEMS INCORPORATED
> 1425 Broadway #320, Seattle, WA 94122
>
> Email:         info at p1.com
> FAX:          +1 206 374-2475
> Web:          http://www.p1.com/
> Voicemail:   +1 206 374-2475
>
> The information contained in this message (including attachments) may be
> privileged and confidential and protected from disclosure. It is the
> property of P1 Systems Incorporated.  If the reader of this message is not
> the intended recipient, or an employee or agent responsible for delivering
> this message to the intended recipient, you are hereby notified that any
> review, dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify us immediately by replying to the message, destroying all
> copies and deleting it from your computer.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20101027/f9d43271/attachment-0001.htm