[Nitro] request parameters

Tim Larson tim at keow.org
Tue Nov 22 11:17:29 EST 2005


On Tue, Nov 22, 2005 at 03:38:58PM +0000, Chris Farmiloe wrote:
> yeah i think the idea is that you could group separate objects
> together for one request just using the naming.
...
> Article = Property.populate_object(Article.new, @params['Article'])
> Comment = Property.populate_object(Comment.new, @params['Comment'])

I understand the above use, but...
> 
> I'm not sure I agree that the values should be duplicated with their
> full names in the request/params hash. I don't think it is much
> to ask that some conventions be followed in naming, _'s would
> visibly tie in with ruby's variables tighter too.
> 
> cat_and_dog looks nicer too ;-)

...this suggestion is not viable when the reason for the periods
is to map to nested data, and underscores '_' are already in use
in simple multi-word names.

The point is that we should be able to use any normally legal
(for CGI programming) request parameter names and be able to
retrieve their values without data-structure-walking gymnastics.

If the framework *also* wants to categorize the request parameters
(making a tree-shaped data structure like it does now) it should
be free to do so...but should not break the traditional CGI-style
programs in the process.

Use two different variables to get at the differently organizations
of the parameters, just picking names out of the air for example:
  request['some.name']
and:
  request_tree['some']['name']

...and since ruby has references (multiple variable names can refer
to the same data,) this would _not_ have to double the memory use
for storing the request parameter data.

> I would like to see further nesting of the "." hashed names...
> ie. cat.and.dog ----> @params['cat']['and']['dog']
> since as it currently stands I think my example above would break if  
> I had
> a Time or Date property :)

Agreed, the nested version does need more nesting.

--Tim Larson



More information about the Nitro-general mailing list