GOTOU Yuuzou wrote:
>In message <3C97D8FB.8090306@imperitek.com>,
> `David Corbin <dcorbin@imperitek.com>' wrote:
>
>>GOTOU Yuuzou wrote:
>>
>>>HTTPRequest is a representation of the HTTP request
>>>messages, and I want the user-defined data to be
>>>managed by the user-defined containers.
>>>
>>The intent behind "attribute" is to be able to set user-data that is
>>automatically get carried along with the rest of the request, and in a
>>very annonymous way. It's perfectly reasonable to expect several
>>different "handlers" to need to "add or extract" data to the "request
>>chain". The only other solution I can see is to add a third argument to
>>all the service, do_GET and do_PUT methods, which is nothing more than
>>the Hash that I put inside the request object.
>>
>
>OK, HTTPRequest will have attributes. But I prefer
>the name of "attributes" which returns a Hash rather
>than "get_attribute" and "set_attribute".
>
I've no problems with that. I'm still adapting to the "Ruby world",
where internal structure is so frequently exposed.
>>You mentioned 'the user-defined containers'. What user-defined containers?
>>
>
>I wanted to say the containers which is held by application.
>
>>>get_instance() is just a factory method. You can also
>>>make it as an instance method which returns itself.
>>>Have you seen httpservlet/prochandler.rb?
>>>
>>Yes, I did see it. But it fails to address the point about *how* I want
>>to create the handler. I thought about that, but I didn't want to build
>>a giant "option" hash.
>>
>
>I cannot understand why a giant "option" hash is built
>by get_instance(). Options are passed from mount and
>it's not duplicated.
>
To be useful, my handler needs a bunch of options. I would rather do
like this
h = MyHandler.new(coreStuff")
h.addFunnyOption ("foo","bar")
h.addFunnyOption ("alpha","gamma")
h.setZoption("gamma")
mount ("/z",h)
than do this
mount("/z",MyHandler {"CoreStuff"=> "coreStuff",
"FunnyOptions"=>[["alpha","gamma"],["foo","bar"]],"Zoption"=>"gamma"})
>
>--
>gotoyuzo
>
>