Re: Camping's URL mapping system
Do you mean this kind of issue: http://stackoverflow.com/questions/3755898/campings-url-doesnt-give-me-site-root-as-expected ? DaveE 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. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 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. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
An A4 piece of paper has a little over 9kb of data storage if storing in binary at 300dpi — Jenna On Saturday, 14 April 2012 at 1:09 AM, Dave Everitt wrote: > There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' > and a great exercise in programming skill, it isn't something that most users > will really worry about. If the 3k limit has to be broken back up to 4 or > even 5k to get some added/altered/optional functionality that would help > usability for the rest of us, it's not an issue for me - DaveE > > > 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. > ___ > 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
Re: Camping's URL mapping system
I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 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. Get the best selection of online sites here. Click Here to check them out! http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
On the other hand, Camping is already far too big to fit entirely in a QR code. It would take as many as TWO QR codes to store camping in it's entirety. — Jenna On Saturday, 14 April 2012 at 1:40 AM, Jenna Fox wrote: > An A4 piece of paper has a little over 9kb of data storage if storing in > binary at 300dpi > > — > Jenna > > > On Saturday, 14 April 2012 at 1:09 AM, Dave Everitt wrote: > > > There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' > > and a great exercise in programming skill, it isn't something that most > > users will really worry about. If the 3k limit has to be broken back up to > > 4 or even 5k to get some added/altered/optional functionality that would > > help usability for the rest of us, it's not an issue for me - DaveE > > > > > 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. > > ___ > > 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
Re: Camping's URL mapping system
For me, this also depends on what Magnus - as the main Camper ninja - thinks - DaveE I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/ optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 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. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
Yeah of course! Cheers! Isak Andersson Dave Everitt skrev: For me, this also depends on what Magnus - as the main Camper ninja - thinks - DaveE I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 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. Choose the Prize you Want to Win, Play PacMan to it! http://click.lavabit.com/ww7o34bkc7cxdk49gqcbw6x8jgi7jrtao1g6b4swpcrtko5bz8uy/ ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
On Thu, Apr 12, 2012 at 16:54, Jenna Fox 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 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 Campi
Re: Camping's URL mapping system
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 (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 b
