[Seaside] WAFileLibrary / Resource Path

[Ken Treis]

On Aug 13, 2007, at 6:37 PM, Sebastian Sastre wrote:

> Hi Ken,
>
> 	maybe is too KISS but I've made this a couple of hours ago because I
> didn't want to manage files manually too much. So with this an  
> image is able
> to write in disk all the libraries that a seaside app uses writed in a
> consistent shape under your image dir.
>
> 	I'll use rewrite rules in apache so copying that file directory path
> should be enough I think. Maybe you find a way to copy that to S3  
> and make
> your apps work in deployment/development by making behave  
> differently in
> #updateRoot: ? Could be "the switch" you asked for?

URL rewriting is an interersting approach, but doesn't really work  
for S3. I need to use a completely different hostname in the URL for  
the files. It seems to fit much more nicely into the idea of using  
the resourceBaseUrl.

Since WAFileLibrary doesn't have a convenient way to generate  
resource-relative URLs -- without "/seaside/files" prepended -- I  
added a couple of methods to accomplish this. It's not strictly  
necessary by itself -- I can replicate the /seaside/files path in my  
S3 bucket, but I didn't want to have to mirror the entire path on S3.

I like the way Seaside 2.8 uses a binary selector #/ for the URL of  
the FileHandler, so I used #* for my more relative flavor. That way I  
can do something like this:

(html image)
	class: 'tl';
	resourceUrl: VisualAssets * #boxCornerTLPng. "returns 'VisualAssets/ 
boxCornerTL.png'"

In #updateRoot:, I didn't want to specify all of the individual  
javascripts and stylesheets, so I added a method to WAFileLibrary  
called #updateResourceRoot:. It works just like the regular  
#updateRoot: but it uses resourceUrl: and the stripped-down relative  
URLs instead. Then I remove all libraries and implement my  
application's #updateRoot as follows:

updateRoot: aRoot
	super updateRoot: aRoot.
	(Array
		with: Seaside.WAStandardFiles
		with: Seaside.SULibrary
		with: VisualAssets) do: [:each | each default updateResourceRoot:  
aRoot]

That way, in development, I can simply set resourceBaseUrl to / 
seaside/files, and in deployment I set it to http://s3.amazonaws.com/ 
myBucket. Deploying to S3 can be done directly from within the image  
without using files, since it's all done over HTTP.

This is how I solved the problem, anyhow. It may be overkill, but it  
works well enough for me.

--
Ken Treis
Miriam Technologies, Inc.