> > locale, url decoding is hard since no encoding information is given in
> > requests, leaving you with lots of options.
>
> Werkzeug supports that with a custom error handling wherever Werkzeug
> works with unicode:
>
> >>> url_decode(u"foo=föö".encode("latin1"), errors="fallback:latin1")
> MultiDict([('foo', u'f\xf6\xf6')])
> >>> url_decode(u"foo=föö".encode("utf-8"), errors="fallback:latin1")
> MultiDict([('foo', u'f\xf6\xf6')])
>
> That can also be defined for custom request objects::
>
> class MyRequest(Request):
> encoding_errors = 'fallback:latin1'
i'll have a look into that.
> But I noted it down and try to fix that when I have time to clean up the
> routing system a bit.
we're just at the beginning. a guess of mine is that we will build
more systems where precisely the naming of methods tells you what
content they deliver for whom in what way. i.e. we get more
linguistic, less computer-speech-like. for example, a lot of (esp.
parameter-less methods) in a typical web-application can be routed by
recognizing their names: instead of [EMAIL PROTECTED]( 'products/list_json' )`
you can write the more natural [EMAIL PROTECTED]( 'list-products.json' )`,
which in turn maps nicely to `def
respond_to_list_products_as_json(...)`, the `respond_to_` part being
indicative of it representing a browsable method, and the `as_json`
part being an indicator of the format. once established, such a rule
could roam the code and publish methods based on their naming.
even if you don't start to build a routing system on top of pattern-
analyzed method names right away, it's still good practice to make
your method names more systematic, so that is appealing: you can first
see what works for you as you define your methods, and later formalize
that knowledge. i am against a lot of the s-c "magic" i've seen going
on in ruby on rails, but i also cannot deny that we always work under
some set of assumptions---i fail to see why those assumptions
shouldn't be adaptable to the purpose at hand.
cheers & ~flow
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pocoo-libs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pocoo-libs?hl=en
-~----------~----~----~----~------~----~------~--~---
