[Nitro] param handling

[Jonathan Buch]

Hi,

thanks for taking the time to answer.

> I don't think the first possibility is a good idea because, like
> Jonathan said, parameters in query strings are inherently unordered.
> However, if Ruby would support named parameters, or, if one could
> annotate the method so that Nitro could find out in which order it has
> to provide the params, I would rather like the first possibility.
> Something like
>
>       ann :action, :params => %w[par2 par1]
>       def action(par2, par1)

Using annotations is quite costly (in facets < 1.7, dunno about 1.7, trans?)
But it would be a possibility to make the version from George run without
inconsistencies, so one could call

	GET /action?par2=foo;par1=bar

and get {:params => [bar, foo]}, I like it, nice idea :)

> Also, I think there is a routing facility available in Nitro - what if
> the route to the method changes? Would there be a problem with the first
> version?

Hmm... no, I don't think so, routes just action on the 'action' part (
template or function name).



> I would vote for the first possibility here because if it happens that
> an action is called without the required parameters, the developer could
> respond with an error message that exactly fits the error. The second
> possibility would just return a general "too few arguments" error.

> This also raises the question how far Nitro should check for errors:
> with the first possibility it would be on action level, with the second
> on parameter level which is just one level deeper. I think that
> checking on action level is enough.

Valid points...

Good points actually.

Slightly unrelated idea:
How about different error pages for different errors?  Like when a
ArgumentError is getting raised, or when a NameError occurs (404)....
Something like a hash with error classes and or error codes...

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png