On Jun 28, 2007, at 9:09 PM, Mark Ramm wrote:

>
>> 1) "response" at a StackedObjectProxy in TG2?
> <<<SNIP>>>
>> I think the "global" response leaves room for a nicer API.
>
(edited to include your intended response)
> Oops, that message got out before I meant it to . I totally agree the
> response object should be available anywhere in the context of the
> controller and all of the pre-post controller "decorator" features.

Ok, I'll look into it. Seems not hard to implement...
>
>> 2) I'd also like to extract a couple of methods from the "route"
>> method so they can be easily subclassed. The first methods that comes
>> to mind is "validate" , "lookup_controller" and "render".
>>
>> However, in order for Pylons' dispatcher not to "expose" them, they
>> need to be prefixed with an underscore. The problem with this is that
>> it's not obvious that those methods should/could be overrided by
>> subclasses since a leading underscore is a python idiom to mark a
>> method private. Another problem is that api docs generators will
>> probably ignore them when documenting the public API.
>>
>> So I'm looking for suggestions on this... some ideas:
>>
>> 1) tweak the dispatcher so it never calls those methods, even though
>> they're not underscore prefixed.
>> 2) come up with a prefix and document it, for example, _tg_validate,
>> _tg_lookup_controller, etc... we'll alose need to tweak the api
>> generator so it document's them.
>> 3) ????
>
> I think most of the methods in PylonsController have the same problem.
>  But pudge has an hack
>
> __pudge_all__ = ['_inspect_call', '__call__', '_attach_locals']
>
> So I'd say we go with _prefixing, and deal with things as they come.
> If we decide to use something other than pudge, we can hack that too,
> and if pylons/paste/toscawidgets move too the hack will be useful to
> others...

Ok. let's prefix them with _tg_ for now?

Just to let y'all know...

I've just placed the blogtutorial app inside tg/tests so we can test  
it form there. It's the same as the one living at pygears but with a  
small hack at __init__.py to fix sys.path (and avoid chaning all the  
blogtutorial imports) and without the egg baggage. More info at  
README-tests.txt

Ive also started test_controllers.py using blogtutorial as the test  
subject and the html output test passes (yay! :). However, the json  
output fails. First because jsonify doesn't know how to jsonify  
pylons.c (should it even be trying??) and later, after I switched the  
include_pylons_variables switch off, it produces totally wacko output  
({u'method': u'index', u'arg': u'test_json.json'}). I'll look at this  
tomorrow and try to implement what I've discussed before...

Anyway, the basis of the testing framework for tg controllers is  
there (albeit a little bit crude still)... please, don't hesitate to  
use it :)

Alberto

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" 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/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to