From: anders@... (Anders Johannsen)
Date: 2001-09-19T17:24:09+09:00
Subject: [ruby-talk:21381] Re: Suggestions for new CGI lib

> I'm not sure what they are for.  The current cgi.rb provides higher
> abstraction not to distinguish get/post/head.  I think unified access
> method (for example cgi.request["user_var"]) is better.  Perhaps cgi.request.var is for this purpose?

cgi.request.var is merged from post, get, cookie and env. 
For added convinience, cgi.request[] and cgi.request.var[] could be
the same.

> What should these methods return?  cgi.rb returns an array of values,
> but it's not convenient for many cases.

A String (since each of cgi.request.(post|get|cookie|env|var)
effectively is a Hash)

> |CGI::Namespace # cgi.namespace
>  
> |  # Introduce new namespace with the indicated variables exported
> |(non-existant variables is   nil)
> |  cgi.namespace.var do
> |    unless non_existant_var.nil?
> |      # Do stuff
> |    end
> |  end   
> 
> I'm not sure what this method does.

In the above example, cgi.request.var['user_var'] is availiable as
user_var inside the block. Non existant variables/methods return nil
instead of raising a NameError exception. Perhaps it is a silly
thought.


> |end # At the end of the block, cgi.print is automatically called
> 
> Should it be cgi.output.flush instead of cgi.print?

I agree.

> What do you think about HTML generation?  Some want it separated from
> CGI.  The current CGI::Session uses this integration.

I would like to see them seperated. CGI is not necessarily used for
HTML.

Anders Johannsen