Joseph Tate wrote:
>
> Lee McFadden wrote:
>> I *don't* think it's a good idea. Controllers are exposed for a
>> reason, they're supposed to be called by the web and at no point will
>> you want your exposed method to return python objects - the browser
>> will not know how to deal with it (and neither will cherrypy for that
>> matter). The reason exposed methods return a string is because your
>> data is automatically JSONified for you.
>>
>> If you want something extensible, create a function that does all the
>> heavy lifting and returns your data how you want it, then use an
>> exposed method to wrap it. That way you can use the wrapped function
>> in any other part of your application or, in fact, any application at
>> all.
>>
>> Lee
>
> Where it does make sense is in test suites, but turbogears already
> provides a method for working around @expose() peculiarities. In fact
> if you really wanted to, you could use something like
> testutil.call(methodname, *params) to get the behavior in code. But a
> little refactoring is preferable.
BTW, using paste.fixture.TestApp you can do:
# somewhere in @expose
if 'paste.testing_vars' in wsgi_environ:
environ['paste.testing_vars']['return_values'] = raw_return_values
# in the test:
res = app.get('/something')
assert res.raw_return_values == {some values}
This exercises the complete stack including template rendering, but also
gives you access to whatever intermediate values you are interested in.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
