Serving files with WAComancheAdapter
Locked
 
|
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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Serving files with WAComancheAdapter
|
|
Tony,
There's no need to create subclasses of WAServerAdaptor for that. You just have to add a 'FileDirectory' entry-point for that. In the /config application, add a new entry point and select 'File Directory' from the drop-down. The rest of the configuration is pretty self-explanatory. For example, if you add the '/css' entrypoint as a file directory that points to '/home/data/project/css', the files from the latter directory will be exposed in ./css url. Johan On 26 Oct 2010, at 19:16, Tony Fleig 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 > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Serving files with WAComancheAdapter
|
|
In reply to this post by tfleig
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 <[hidden email]> wrote: I want to serve CSS and Javascript files from an on-disk directory (i.e. not using WAFileLibrary) and also not using Apache. -- http://john-mckeon.us _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Serving files with WAComancheAdapter
|
|
such a solution is useful while you are developing because:
- it allows to use external files rather than in-image FileLibrary method and thus work with external editors on css, javascript, etc... files - avoid the need for setting up and maintaining an apache config on your development computer For deployment, it's obvious to use Apache for serving static files rather than passing them through the Smalltalk VM Johan On 26 Oct 2010, at 21:05, John McKeon 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 <[hidden email]> 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 > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > -- > http://john-mckeon.us > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by John McKeon
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 <[hidden email]> wrote:
-- P1 SYSTEMS INCORPORATED 1425 Broadway #320, Seattle, WA 94122 Email: [hidden email] 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. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Serving files with WAComancheAdapter
|
|
I also use apache to serve all my css and javascript files. Response
time is much better from apache than the image for serving these files. Also editing these files is much easier in tools like dreamweaver. To sync these files between my laptop, pc and VPS i use Dropbox :) Drop box will pick up any changes to the directory and distributes it to all connected PC's. Aslo my designer works with this shared folder, so there is no overhead with transferring these static files or waiting for updates:) HTH, Bart 2010/10/26 Tony Fleig <[hidden email]>: > 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 <[hidden email]> 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 <[hidden email]> 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 >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> >> >> -- >> http://john-mckeon.us >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > > > -- > P1 SYSTEMS INCORPORATED > 1425 Broadway #320, Seattle, WA 94122 > > Email: [hidden email] > 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. > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by tfleig
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 <[hidden email]> 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. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Serving files with WAComancheAdapter
|
|
2010/10/27 Tony Fleig <[hidden email]>:
> 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? There are three reasons. First is it's not ideal from a performance point of view because it contains something like four wrapper layers. Second it isn't used a lot. Third the licensing is LGPL whereas the rest of One-Click it MIT. We recommend experienced users, especially ones going into production, to load only the parts the need. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Ok. Thanks much for the info.
Follow on noob questions: 1. Should I assume that after executing the Gofer load that I now have all the Seaside components?
2. Squeaksource shows a large number of Seaside packages. Are they community-provided as opposed to packages directly from the Seaside project? TF
On Thu, Oct 28, 2010 at 9:19 AM, Philippe Marschall <[hidden email]> wrote: 2010/10/27 Tony Fleig <[hidden email]>: _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Serving files with WAComancheAdapter
|
|
2010/10/28 Tony Fleig <[hidden email]>:
> Ok. Thanks much for the info. > Follow on noob questions: > 1. Should I assume that after executing the Gofer load that I now have all > the Seaside components? Everything of the Seaside 3.0 release for Pharo including the tests and two web servers. > 2. Squeaksource shows a large number of Seaside packages. Are they > community-provided as opposed to packages directly from the Seaside > project? Packages from the following two repositories are from the Seaside project: * http://www.squeaksource.com/Seaside30 * http://www.squeaksource.com/Seaside30LGPL * http://www.squeaksource.com/Seaside Other repositories are probably community-provided. Cheers Philippe Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Serving files with WAComancheAdapter
|
|
In reply to this post by Philippe Marschall
On 28 Oct 2010, at 18:19, Philippe Marschall wrote: > There are three reasons. First is it's not ideal from a performance > point of view because it contains something like four wrapper layers. > Second it isn't used a lot. Third the licensing is LGPL whereas the > rest of One-Click it MIT. Maybe the second reason is because it's never mentioned? :-) I always wonder why people seem to use the WAFilelibrary so often in Seaside development, while it's probably the most horrible experience to develop your js and css in Smalltalk strings. IMO, the package has great value during development because it permits to serve external files via the in-image webserver. This means I can use decent text editors to edit javascript and css without having to install and maintain an external webserver (e.g. Apache) on my development machine. As for performance, I don't care about that during development. Johan_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Philippe Marschall
Thanks very much for this information, Philippe.
TF
On Thu, Oct 28, 2010 at 11:11 PM, Philippe Marschall <[hidden email]> wrote: 2010/10/28 Tony Fleig <[hidden email]>: _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |