R(c,*g) helper method can't handle nested hash input params

params= {"search"=>"Search", "date_begin"=>"2007-05-01", "date_type"=>"created_on", "order"=>1, "report_type"=>"year_end", "person"=> {"reply_status_id"=>"1", "created_on"=> Tue, 01 May 2007 00:00:00 +..Fri, 23 May 2008 00:00:00 +}, "date_end"=>"2008-05-23"} R(Report,params)

Re: obfuscation Re: Rack, Camping 2.0++

2008/5/22 Ernest Prabhakar <[EMAIL PROTECTED]>: > So, it sounds like there's a few options: > > a) Automate the creation of the obfuscated version from the unabridged > version Last time I checked, Ruby2Ruby didn't recognize all camping constructs but it might be better now. > b) Tweak the system

Re: obfuscation Re: Rack, Camping 2.0++

The problem is that almost all app require 'camping' and when bin/camping require 'camping-unabridged' things gets pretty messy. (I just realized that bin/camping could monkey-patch require such that when the --unabridged-flag is set it require 'camping-unabridged' instead of 'camping'. But that's

Re: An issue for consideration

Good find! 1. If you run that on a real HTTP server (Apache, Nginx etc.) it will just ignore it. Remember that Mongrel/Thin should be served behind a proxy and are "lazy" about checking valid request. 2. A cool thing with the Rack-rewrite is that you can use Rack::Lint to validate the requ

Re: An issue for consideration

Yeah I think it'd be good, or if not just make it not work on helper methods, just class methods in the controller, then it wouldn't be so nasty and unexpected. It's good to hear i'm safe behind apache. On 23/05/2008, at 8:16 PM, Magnus Holm wrote: Good find! 1. If you run that on a real

Re: obfuscation Re: Rack, Camping 2.0++

> The problem is that almost all app require 'camping' and when bin/camping > require 'camping-unabridged' things gets pretty messy. Right, didn't thought about that.. well then we have to come up with a Ruby2Ruby version, isn't it ? ___ Camping-list mai

Re: An issue for consideration

On May 22, 2008, at 10:46 PM, Bluebie, Jenna wrote: We've just come across an issue for consideration. I am avoiding some words which would allow people to find this message in an internet search who have questionable intentions, but wish to communicate a strong sense of caution. Consider

Re: An issue for consideration

On Fri, May 23, 2008 at 12:16:15PM +0200, Magnus Holm wrote: > Do you think we should add a protection inside Camping too? No, if Rack comes with Rack::Lint and Camping now depends on Rack, then it'd be redundant to have it in Camping as well, you know? _why __

Re: obfuscation Re: Rack, Camping 2.0++

How is camping.rb created from camping-unabridged.rb? By hand? If that's the case, you can't expect the compressed camping.rb to be maintained once more than _why and zimbatm start wanting to contribute, you know? If it can be done by script, then by all means let's do that and include that scri

Re: obfuscation Re: Rack, Camping 2.0++

> How is camping.rb created from camping-unabridged.rb? By hand? Err.. yes. This is a kind of art you know ? ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list

Re: Rack, Camping 2.0++

2008/5/22 _why <[EMAIL PROTECTED]>: > Splendid! If we can say Camping, the 3K Microframework, then I > think we will really have a reason to bump the big number. I'll wait > for a reaction from zimbatm, but I am euphoric about these changes. Wasn't the one who codes who leads ? :) __

Re: Camping-list Digest, Vol 23, Issue 8

What pains me is that my Perl clone is weighing in at a bloated 6.6k after I run it through: cat `find -name '*.pm' -print` | perltidy -npro -dac -dws -i 0 | sed '/^\s*$/d' | perl -pe 's/ +/ /g' | wc . I was never an expert golfer , but still *sigh* --beppu

Re: Rack, Camping 2.0++

So should I just merge/rebase everything to my master, so _why can merge it into his? Some more notes: * camping/db.rb -> camping/ar.rb * camping/session.rb -> camping/ar/session.rb * CookieSession -> camping/session.rb The documentation and the names (Camping::Session, Camping::ARSession?) needs

Re: Rack, Camping 2.0++

Does being implemented on top of Rack mean that Camping will get the concurrency described on pages 17..21 of http://yeahnah.org/files/rack-presentation-oct-07.pdf ? ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/lis

Re: An issue for consideration

On Fri, May 23, 2008 at 04:20:21PM +1000, Bluebie, Jenna wrote: > This should help. include Camping::ControllerSecurity in your controllers > module or your Camping (or whatever Camping.goes has turned it in to) > module, after requiring this: > >> module Camping >> module ControllerSecurity >>

Re: Rack, Camping 2.0++

2008/5/23 Magnus Holm <[EMAIL PROTECTED]>: > So should I just merge/rebase everything to my master, so _why can merge > it into his? Some more notes: > > * camping/db.rb -> camping/ar.rb > * camping/session.rb -> camping/ar/session.rb > * CookieSession -> camping/session.rb > > The documentation an

Re: An issue for consideration

You at least want to allow what's in the HTTP spec -- that's HEAD, TRACE, OPTIONS, and CONNECT, on top of the GET/POST/PUT/DELETE. -- Eric On Fri, May 23, 2008 at 7:21 PM, Brendan Taylor <[EMAIL PROTECTED]> wrote: > On Fri, May 23, 2008 at 04:20:21PM +1000, Bluebie, Jenna wrote: >> This should he