On Thu, 16 Mar 2000, Bolot Kerimbaev wrote:
> there were several fixes (4.1-4.5) that included #body and the fix
> necessary for the #body to work.
>
> bolot
Er..but it *didn't* work ;) The problem is that afaict, #body: won't get
called in the normal run of things. When I did this, everything worked
fine:
postFields
"Answer the multipart fields for a post request (if in fact this
is a
POST request"
^self propertyAt: #postFields ifAbsentPut: [
" parse POST fields in the body of request, if it's
standard form data "
(self isPostRequest and: [
self contentType = MIMEDocument
contentTypeFormData
]) ifTrue: [
self class decodeUrlEncodedForm:
(stream next: self contentLength).
] ifFalse: [
self body: (stream next: self
contentLength). Dictionary new
"Get the body! And initialize the dictionary."
].
].
I don't know if it's timeout problems or what, but there's a severe case
of premature termination (eek!), if I just try calling body (of course,
#body does nothing with the stream, so I suspect this bit of code should
go *there*. But this is where I was when I fixed it :))
For fun, folks, if you can read text/xml, try:
http://beauvoir.phil.unc.edu:8080/chat/
You can get a particular message by number:
http://beauvoir.phil.unc.edu:8080/chat/messages/1
If you have a little posting client (I'll have one soon), post to:
http://beauvoir.phil.unc.edu:8080/chat/messages
With content-type=text/xml and the body being just like the message
format, except you can leave out the date element.
If you want to post it from IRC, it's currently monitering /server
casbah.org, channel #casbah.
I refactored my inital hack into a bloody mess ;) I was trying to use the
following methodology:
#filter: is about URLs. It should pass URLs which the module can handle,
404 or redirect one's it can't. I think the 404ing/redirection should be a
default behavior, actually.
What #filter: passes out is a request, typically tailored to the module
(e.g., in this case, the request passed out knows about channelName and
msgID). However, this led me to a proliferation of Request classes, one
for each general "kind" of request. Well, that's not quite right. I ended
up with one for each kind of *object* requested.
This had the potential to really uck up DWChatModule>>process:. My first
move was to have helper methods (#processChannelRequest, etc.), and this
would have been fine, except I ended up replicating a lot of
"filtering" or "dispatching" code in both #filter: and #request:. Yeck. So
I made #filter return specific kinds of request for each kind of object
and put the processing code *into* the request!
I ended up with:
process: rawRequest
| request |
request _ self filter: rawRequest.
^request processWith: self
That's actually not so bad, as a *framework*. But I'd hate to have to come
up with it each time. So, either this should be in ComancheModule itself
(and what module writers spend their time doing is writing #filters and
Request classes) or I'm seriously confused :)
Actually, I wouldn't mind reifying filters as well. Indeed, it could be
*very* tasty to use the Prolog matching stuff on urls! Heh heh.
(BTW, mostly for Bolot :), I'm using your Prolog/V port to implement a
message sorting expert system. A toy one! but that will be used to deal
with a real message stream. Good fun.)
Cheers,
Bijan.
