On static files: Sure, there are ways to have a server do your static files for you, but those ways are inconsistent and require strong knowledge of servers - further, they limit Camping's ability to do smart things with cache control. As a framework which tries to be friendly to beginners, deployment is in my opinion our biggest problem today. Most people do not need the questionable performance benefits of serving static files at the reverse proxy layer. All of my camping apps serve from the app-server via crazy messy config.ru files. As a ruby person, I never want to spend time messing with web server config files if I could just do it in ruby all in the one place.
On filters: Defining methods is no good - one of the primary uses of filters is authentication - something you'd want in many controllers but not all, or applying only post methods but not get sometimes. This is why being able to reference a method from helpers on a per-method level is really great. Defining a before() method on the class is also bad, because what then happens if you do a HTTP BEFORE request? Camping has always been friendly towards HTTP's support for arbitrary methods, and it'd be a shame to see that go. The cleanness of the class's methods being the http methods precisely is important to me. Being able to set and unset the before and after's as a state machine just like with private, protected, and public, I think is the best syntax for this. It's just like protecting a method you don't want web accessible. After is useful, for instance how I processed headings in the camping.io site - each heading needed to be replaced with more complex markup to handle multiple typefaces for the colours - so I do a gsub. Nokogiri would have been another great way to do it - perfect for an after filter. The way I ended up doing it was pretty messy. On self/: The current behaviour is confusing, as it is not how HTML works. In all other times when you pass a string in to markaby like that, it just uses that string as the attribute value. R(Controller) should return a relative URI::HTTP, as with local(arg) returning a relative uri to the file handler (effectively R(Files, arg)). How about we make the handling of URIs magic and leave strings as the attribute's actual unprocessed value. An absolute URI (beginning with / in path) should be pretty much just to_s'd, while a relative uri would be merged with the (self / whatever) logic. In fact, URI already is smart enough to do exactly this and also handle URIs pointing to other servers. All we need is a URI pointing to the app's root, then we just URI#merge with the argument URI. The main problem today is that when you write '/something' camping modifies it with self / '/something' and it ends up being '/app/something' - not how HTML works. The only way to reference things outside the camping app's mount point that I know of is '/../something', which camping outputs as '/app/../something', and which some web servers are happy enough to process, undoubtably with a performance hit. It just looks silly when you look at the resulting pages and their URLs, and if you're using it for links it's even worse - it could negatively affect mirroring bots by creating many URLs which point to the same file. Googlebots and the likes do not like that. There's also another opportunity here - if we make the (self / x) merge happen inside of R() and local() we can expose those to the public ruby environment and you can have say, three camping apps mounted and from your Gallery app you could call on your Guestbook's R() and local() methods somehow and get absolute urls to it's controllers, so you could do easy links between camping apps. Not sure how to make Guestbook.R(Controller) work though since the Controller is inside Guestbook::Controllers and not in the Gallery. Maybe the external syntax changes a little to R(:SignWall, 'fred'). In fact, the whole controllers being referenceable everywhere thing is a bit magical at the moment - maybe we should just deprecate the syntax and switch to symbols. Symbols syntaxically look worse. Maybe there's another way which would be nice and tidy but also not depend on shuffling references to constants all over the place. — Jenna On Saturday, 14 April 2012 at 5:37 AM, Magnus Holm wrote: > On Thu, Apr 12, 2012 at 16:54, Jenna Fox <a...@creativepony.com > (mailto:a...@creativepony.com)> wrote: > > 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. > > > > > Yes, and when you're deploying there are better ways to serve static files. > > > 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. > > > > > What about something like this: > > module App::Controllers > class Index > def before > p "before #{@method}" > super > end > > def after > super > p "after #{@method}" > end > end > end > > They can also be overridden at app-level: > > module App > def before; … end > def after; … end > end > > It's probably 40 more bytes. > > > 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. > > > > > That doesn't seem like an optimal solution either. That means that I > can develop an app like this: > > def view > a "Hello", :href => R(Hello) > end > > And it works great in development, but deploying on a sub-path is > going to be a pain because I need to wrap everything in local(). > > I'm really not sure if there's a good solution here. Right now Camping > optimizes for local URLs which seems more useful than optimizing for > external URLs… > > There are ways to make it work correctly in both cases, but they are > kinda ugly/magic. R(Hello) can return an instance of a subclass of > String and `self/` will only expand the string if it is_a?(Internal). > Again: I'm not sure what the best solution is :-( > > > 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 (mailto:Camping-list@rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > 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
