I understand about the loose coupling, but I think there is some
misunderstanding about the very nature of 'loosely coupled'. Coupling
has to do with *dependency*, not just utility. Adding a decoupled
method to the request is not a restrictive assumption, it is what it
is - a shortcut. No-one is 'forcing' a user to call the method, and
nothing will depend on the coupling given by render_to_response. Tight
coupling is only ever a problem when there are dependencies on the
coupling; then it gets messy.
Indeed, we could argue that the admin interface is disgustingly
coupled - the template layer, the database layer, the URLconf and the
views are all so very intricately coupled, but the thing is, no-one is
*depending* on the admin app to be loosely coupled (and permit the
interchange of ORMs, etc.), so it's not an issue. Likewise for a
proposed request.render method. It's just an issue of what namespace
it is in, and putting it under request will be a quick way of saving
verbosity, time and money. No death or injury will occur in the
process, I assure you.
On Nov 21, 5:25 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 20, 2008 at 10:23 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Nov 20, 2008 at 9:47 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> >> On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote:
> >> ...
> >>> # Using RequestContext
> >>> def myview(request, *args):
> >>> # some code here...
> >>> request.render('template_name.html', {...})
> >> ...
>
> >>> That just seems logical to me. Rather than (potentially) break
> >>> backwards compatibility, let things be as they are right now and just
> >>> add a method to the request.
>
> >> Except that it couples request and response objects to templates.
>
> > But render_to_response also does that?
> > You want request and response to be loosely coupled? Does it make
> > sense? Aren't they coupled in render_to_response and response
> > processing code anyway?
>
> > Please explain your point a bit more.
>
> render_to_response is a "shortcut" that makes a few assumptions to
> cover a common use case and helps keep your views DRY. If you changed
> your template system or various other pluggable components, you would
> either need to write your own version of render_to_repsonse or repeat
> yourself often in your views. However, by making render a method of
> the request, we are now taking those assumptions another level and
> forcing them on the request object itself. That's bad.
>
> You see, anyone can use Django any way they want and don't have to use
> any of the "shortcut" helper functions. However, everyone has to use
> the request and response objects, so the code needs to make as few
> restrictive assumptions as possible in those objects. And yes, making
> it easy for someone to use a different template system is a feature
> that we want to keep.
>
> --
> ----
> Waylan Limberg
> [EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
