[Seaside] WAFileLibrary / Resource Path
boris at deepcovelabs.com
Thu Aug 2 22:09:49 UTC 2007
My deployment script just gathers all files from all libraries and pushes them to s3 with the rest of it and then links to them from updateroot after removing those classes from libraries collection. I didn't need to hack anything to get it to work and it was reasonably easy to do.
(Sent from a 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: Thu Aug 02 15:05:59 2007
Subject: Re: [Seaside] WAFileLibrary / Resource Path
On Aug 2, 2007, at 1:46 PM, Patrick Collison wrote:
> Libraries are designed to be served from Seaside,
Sure, and it works great that way for development. They keep my small
static assets in the same version-controlled bundle with my code. But
when it comes time to deploy, I'd like to be able to squirt them up
to S3, flip a switch, and have them served from there instead.
> and those SULibrary
> files are just the standard Scriptaculous distribution that comes
> bundled with Seaside.
I thought so too until I looked at them. The treePatch.js file isn't
standard as far as I can tell. I haven't compared the other files to
the distribution, but that's the point. I don't want to compare them.
I want to push them up once at deployment and know that they're
identical to the files I've been testing with.
Even if I use updateRoot: on my component to do this for
Scriptaculous, I would still need a solution for WAStandardFiles. I
think I will add a setter for WAApplication>>libraries: so that I can
force them to an empty collection. Then I will use my app's
#updateRoot: to set them to resource URLs.
Thanks everyone for the suggestions.
Miriam Technologies, Inc.
Seaside mailing list
Seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Seaside