WsgiRequest not in colubrid ?!

[manatlan]

I like the second method on this page :
http://trac.pocoo.org/wiki/RequestResponseMockups

but it doesn't work with colubrid 0.10 ;-(
it miss WsgiRequest ... which not in the module colubrid ...

what is the trouble ?!?
or how to adapt this second method now ?

[Armin Ronacher]

Hoi,

manatlan wrote:
> I like the second method on this page :
> http://trac.pocoo.org/wiki/RequestResponseMockups
>
> but it doesn't work with colubrid 0.10 ;-(
> it miss WsgiRequest ... which not in the module colubrid ...

That's just a mockup. The final implementation looks slightly different.
Have a look into the documentation[1].

Regards,
Armin

[1]: http://wsgiarea.pocoo.org/colubrid/documentation/

[manatlan]

that is what i am looking for ...
(i come from webpy ...)
i'd like to return iterator, string or httpresponse object ...
i can't find this implementation ...

should i understand i should developp this implementation ?!

[Sol]

> (i come from webpy ...)

Let me know how your migration worked out, once it is done. I'm still stuck
to web.py.

--
Cheers, Sol.

[manatlan]

i read the documentation many times ...
but it seems it's out of date

the object ResponseRequest is not present too !?
http://wsgiarea.pocoo.org/colubrid/documentation/request/#responserequest

this line : give a "ImportError: cannot import name ResponseRequest"
from colubrid import ResponseRequest

[Armin Ronacher]

Hoi,

The ResponseRequest object is defined in the colubrid.request module but
we don't recommend using it. The better way is returning response
objects from the view functions.

Regards,
Armin

[Armin Ronacher]

Hoi,

I would recommend that you grab a template engine and write a decorator
which you can apply to the view functions than.

Regards,
Armin

[manatlan]

Since my post i had found the "ResponseRequest" object ...
i'd tested it ... and i understand why it's not recommended to use ;-)

in fact, i made a lot of tests with colubrid ... and finished to do
what i wanted
I've learned a lot from colubrid ...

In fact, i was a big fan of cherypy in the past. And fall in love of
webpy since the first hours !
And i like colubrid now (but i need to learn more) ... it's a good shot
... between CP2 and webpy !
It's less a "framework" than webpy ! It's more low level !
I like this low level api : able to work at the process_request and at
the creation of the request object ... so it makes really easy to build
a framework !!
I like the idea of the application dispatcher (easy to code like CP2 or
webpy, or what you like)
i like the exception handling, and the good wsgi base, and the class
layout !
Like you say on the front page : it's not a framework ! but it let's
you make your framework easily, with wsgi compliant !!! (i love that)
it's not as magic as webpy (a lot !)... but in fact : it's what i like,
because i can make my own (easier to use/hack), and make the magic
myself ...
I like the python2.2 compliant (by hosting provider use 2.3 ;-( ... and
i work with 2.5 on my box)

i don't like the use of the paste internal wsgi server ... it should be
provided in colubrid (like in the past, as i read in the doc) ... and
it seems it breaks your reloader system.
(in fact : i like standalone module)

congratulations for your work
i will still try it, and perhaps i could switch

[manatlan]

I dive more and more in colubrid ...
It is well programmed : i understand all ;-)
and thanx to colubrid because it really teach me what is really wsgi
and how it really works. (i can't say this with webpy, full of magic)

And like i already said, colubrid is not a real framework, it
implements nicely a wsgi app, with a nice separation of request and
response object, and a well dispatcher application. (and debug, reload,
etc ...)

I really think it should include a httpserver ! Because if you need to
install paste, you don't need to install colubrid ... a lot of things
are already in paste (debug, reloader, ...)
So if you wan't not provide an httpserver you shouldn't provide a
reloader or a debuger, in the same logic ...

(the reloader of PASTE is better, because the (old) reloader of
cherrypy as the well know trouble :
On some platforms server threads may not terminate when the main
thread does, causing ports to remain open/locked. The
``raise_keyboard_interrupt`` option creates a unignorable signal
which causes the whole application to shut-down (rudely).
it's the case for me, on edgy and win xp)

Now i think i will stick on WSGI only ...
thanks to your great works ! it helps/learns me A LOT !