Hi Ben,
> So here's some equivalent statements:
> render('/some/template') == render('/some/template', response=False)
> render_response('/some/template') == render('/some/template')
> response('some string') == render('str', 'some string')
>
> I'm not particularly happy with this arrangement though, and using a
> template engine called 'str' to render a string is pretty hackish.
>
> Of course, alternatively, maybe there's no reason to unify the render
> commands, and the current setup is just fine. :)
>
My personal preference is for what you have already. The user can do two
different things, one is returning a response, the other is rendering a
template to a string. Although the two might be related on end-user
conceptual level they are technically different so I think we should
keep them separate, making them into the same function would probably
just confuse people. You could scrap render_response() if you really
want to but I like that as a convenience method.
Of course there is no harm in coming up with a new method called say,
display() which acts in the way the render() method you are proposing
does then people can choose whatever suits.
> I've removed render_fragment and render_response_fragment from 0.9.
> The new syntax for fragments is to just include it as a keyword:
> render('/some/template', fragment=True)
>
> I think this clears up some redundancy and having just render and
> response with a render_response shortcut is sufficiently concise.
>
You beat me to it, OK, we're agreed ;-)
James
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss
-~----------~----~----~----~------~----~------~--~---
