bin/camping is great but it's not usually a good way to deploy an app on a server - it tends to be more for development. Putting functionality in to bin/camping which belongs in camping core is like wearing a backpack filled with hydrogen while having your weight checked. 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature.
I think we should have a little line you write right in to your app file which says where you keep your files. Something like MyApp.files = 'public'. Maybe that's the default. 'just redefine service' isn't a good solution no matter how many times you post it on this list. I shouldn't need to lookup any references or archaic mailing list archives to do something so simple in a new project. For the local file urls thing, I propose a breaking change (eg: camping 3.0) the addition of a method named local() # for now it looks like this: def local arg self / arg end and the removal of magic (self / arg)ification of href and src attributes in markaby templates. local() should eventually talk to MyApp.files and the file serving feature so they can all work together nicely - all the code for that should be in one place, maybe in one class. Using local() adds some interesting opportunities too. It'd be really easy to modify local do to other stuff, like load your files from a database, or make urls which reference files by their inode number instead of their file path, or have it return data uris, or have it generate Amazon S3 urls with one time keys in them, or include the file's mtime in the url, allowing the server to specify month-long cache durations while apps instantly pick up changes, making them feel super responsive. One more thought - on file serving, I think it'd be nice if the default was that local files are served out of /files/ url rather than just being at the app's root level. I know this would be controversial: It would be really clear to beginners, and if someone writes img(src: 'files/blah.png') camping can raise a warning explaining the img(src: local 'blah.png') syntax. It also means web servers would need to be explicitly configured to duplicate that behaviour at a lower level - a simple quick camping setup would always serve files through camping, making debugging easier and applications more reliably portable. People who need the performance boost of doing it at the web server level can do that - it just wont happen by default. Deployment is one of the biggest hassles we face - this may help. — Jenna On Friday, 13 April 2012 at 12:26 AM, Magnus Holm wrote: > On Thu, Apr 12, 2012 at 15:59, Jenna Fox <a...@creativepony.com > (mailto:a...@creativepony.com)> wrote: > > The problem is basically this: > > > > Sometimes you want to reference static files, and other components of your > > site. I have a Gallery app mounted at http://creativepony.com/gallery/ and > > it causes me all sorts of trouble. Often times to reference static files I > > end up needing to use /../ in URLs inside of views and controllers, which > > webservers surprisingly correctly translate in to the wanted files, most of > > the time. Other times I want to reference other camping apps mounted in the > > same server instance via a rack URLMap. > > > > I know as I say this someone will paste a function I can redefine with some > > boggling ultracompressed camping code inside, where every variable is a > > letter - but I have work arounds which work. The trouble is that hacking > > about like this just isn't fun. > > > > In my opinion Camping needs in it's core static file serving > > bin/camping should serve public/ > > > , catchall before/after methods for controllers, > > module App > def service(*) > p :before > super > ensure > p :after > end > end > > > and I have no idea how, but we need to > > fix the insanity which is the (self / arg) thing being applied to all src > > and href values in markaby templates. It's a great idea and I love it when > > it works, but it's so often a leaky abstraction for me, and when it leaks, > > there's no clear solution! > > > > > I agree, although I don't have any elegant solutions… > _______________________________________________ > Camping-list mailing list > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
