[Seaside] SULibrary and File Serving

[Sebastian Sastre]

I agree with you in starting simple. The problem arrives when you need more.
I find a good idea to take one crisis at the time :) and start simple until
you really have to make next step. An ant can cover large distances.

In this stage I use rewrite rules, they are a total pain in you know where
but when they work they do it very well. I don't need to proxypass at all.

Just for reference:

	...
        # proxy by rewritting to seaside if file not found
        RewriteEngine On
        RewriteLog /var/log/apache2/dev.ceaec.seaswork.com.rewrite.log
        RewriteLogLevel 9  <--- only when debuging rewrite rules (0 for
production)

        # 1. Try to find the request as a regular file in the document root
	  # and if exists serve it
        RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} -f
        RewriteRule ^(.+)       %{DOCUMENT_ROOT}/$1 [L]

        # 2. This is optional. If not there, see if the url says it's a file
resource (by detecting 
	  # /applicationFiles* in the path that I artifially introduced in
image)
        # if so, then rewrite it to the libraries in the image
        RewriteCond %{REQUEST_URI}     ^/applicationFiles*
        RewriteRule ^/(.*)$    http://localhost:9090/%{REQUEST_URI} [P,L]

        # 3. Send to the application if matches a typical seaside url
        RewriteCond %{REQUEST_URI}      appName*_* [OR]
        RewriteCond %{REQUEST_URI}      index*
        RewriteRule ^/(.*)$     http://localhost:9090/appName/$1 [P,L]
	...

	Notes: this needs the hack that cuts the /seaside/ in the dispatcher
but maybe gives ideas even using /seaside/ in the path.

	I've only tested this with normal seaside url (not pretty ones)
	I think this will scale reasonably easily (I mean apache conf only)
to hit a proxy of balanced images when needed instead of localhost:9090
attended by one image like I have now.

Sebastian Sastre
PS: several technologies seems to be solved similarily when using apache as
front end so conserve your hair !!

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Richard Eng
> Enviado el: Lunes, 08 de Octubre de 2007 13:59
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] SULibrary and File Serving
> 
> I've solved my problems!!! After *much* trial and error (and 
> after *much* hair-pulling), I've learned a number of 
> important lessons. And just so none of you go through the 
> same hell that I did, I'm going to impart my hard-earned 
> knowledge to you...
> 
> (Here's the final httpd.conf I'm using:
> 
> LoadModule  proxy_module  /usr/lib/apache2/modules/mod_proxy.so
> LoadModule  proxy_http_module  
> /usr/lib/apache2/modules/mod_proxy_http.so
> LoadModule  rewrite_module  /usr/lib/apache2/modules/mod_rewrite.so
> 
> NameVirtualHost 192.168.1.101:80
> 
> <VirtualHost 192.168.1.101:80>
> RewriteEngine     on
> ProxyRequests     off
> DocumentRoot      /var/www
> ProxyPass         /seaside/go  http://localhost:9090/seaside/go
> ProxyPassReverse  /seaside/go  http://localhost:9090/seaside/go
> RewriteRule       ^/$  http://localhost:9090/seaside/go/$1 [P,L]
> </VirtualHost>
> 
> It doesn't matter how the Seaside image itself, ie, WAKom, is 
> configured for file serving.)
> 
> First, despite what Lukas said, you *do* need the ProxyPass 
> and ProxyPassReverse directives in Apache. When I used the 
> rewrite rule by itself, I ran into the same problem I 
> experienced before with the Seaside
> 2.8 beta dev image, ie, the initial home page rendered 
> correctly and with the correct IP address prefix, but 
> navigating to subsequent pages got me the "localhost:9090" prefix.
> 
> Second, the #setFocus on text input field problem I alluded 
> to earlier is a direct consequence of the file serving 
> problem, which is the primary focus of this message thread.
> 
> Third, the whole issue boils down to where, *exactly*, is 
> Seaside looking for the library files. Various blog posts 
> were not entirely accurate, and therefore misleading. My 
> final clue to the mystery came from Seaside config's "file" 
> configuration. This led me to surmise that perhaps the proper 
> Seaside URL for locating its internal library files was 
> /seaside/files/SULibrary/scriptaculous.js, for example.
> 
> Now the next question was, to what filesystem folder should 
> this URL be based? Since Apache is configured to serve files 
> only from /var/www, it made sense that the Seaside URL should 
> be here. So I moved all the files I extracted from Seaside 
> (WAStandardFiles and SULibrary) to:
> 
> /var/www/seaside/files/WAStandardFiles
> /var/www/seaside/files/SULibrary
> 
> Fourth, in order for the file serving to work properly, the 
> ProxyPass directives must be coded correctly. This means 
> that, for example,
> 
> ProxyPass         /seaside/go  http://localhost:9090/seaside/go
> 
> ...is correct, but
> 
> ProxyPass         /go  http://localhost:9090/seaside/go
> 
> ...is incorrect. "/seaside/go" must match with 
> "localhost:9090/seaside/go".
> This is where I went wrong in my original httpd.conf file.
> 
> 
> One final comment: My approach to problem-solving is to 
> distill everything to the simplest basis. While there are 
> several instances of Apache configuration in various Seaside 
> blogs, they tend to be fairly complicated and therefore it is 
> difficult to understand how or why they work.
> 
> This post simplifies to, and focuses on, the absolute minimum 
> basics. From here, you can get as fancy as you like. It is 
> not good to start off with a complicated httpd.conf configuration.
> 
> Regards,
> Richard
> 
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside