Re: class based views: object instead of dictionary as context?

[daonb]

Hi Reinout,

IMHO, Django's philosophy is that template designers are highly
skilled designers and not coders.  To make it possible for designers
to edit the templates themselves, Django requires the developer to
create a simple context dictionary for designers to understand.

In all of my projects so far I didn't have the luxury of a designer
who'se fluent in Django templates and can write them by himself, but
still, I like Django for showing a clear way for designers and coders
to work together.

Benny

On Sep 1, 11:46 pm, Reinout van Rees  wrote:
> Hi,
>
> I've got one big what's-the-design-decision/reason question regarding
> django 1.3's new class based views: why does django encourage a
> hand-crafted context dictionary instead of "just" passing the view
> object along?
>
> In zope/plone, I was used to having the view object available in the
> template as 'view'. The django equivalent would be to pass a context of
> {'view': self} to the template.
>
> All the attributes on the view class (well, object) would be available.
> Django prefers the template to stay simple and stupid: what could be
> better than encouraging to just add extra methods to the class if you
> want something special? Now you have to add the method *and* pass it
> along in the dictionary. Double work?
>
> Passing the view object to the template by default seems to me to be an
> absolute no-brainer. Class based views ought to mean you get the view
> object in your template, right? But Django doesn't do it. So... is there
> a specific reason for it?
>
> Reinout
>
> --
> Reinout van Rees                    http://reinout.vanrees.org/
> rein...@vanrees.org            http://www.nelen-schuurmans.nl/
> "If you're not sure what to do, make something. -- Paul Graham"

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

class based views: object instead of dictionary as context?

[Reinout van Rees]

Hi,

I've got one big what's-the-design-decision/reason question regarding 
django 1.3's new class based views: why does django encourage a 
hand-crafted context dictionary instead of "just" passing the view 
object along?


In zope/plone, I was used to having the view object available in the 
template as 'view'. The django equivalent would be to pass a context of 
{'view': self} to the template.


All the attributes on the view class (well, object) would be available. 
Django prefers the template to stay simple and stupid: what could be 
better than encouraging to just add extra methods to the class if you 
want something special? Now you have to add the method *and* pass it 
along in the dictionary. Double work?


Passing the view object to the template by default seems to me to be an 
absolute no-brainer. Class based views ought to mean you get the view 
object in your template, right? But Django doesn't do it. So... is there 
a specific reason for it?




Reinout

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Exceptions thrown from middleware

[Tom Evans]

Hi all

Currently, if a view throws an exception, the middleware classes that
have a process_exception method will be called in reverse order to see
if one of them can handle it and return a valid response before
django's default exception handling takes over.

This doesn't hold true for middleware classes themselves - any
exception raised from a middleware's process_{request,view,response}
is immediately handled by django's default exception handling, and
there is no way of handling that exception more cleanly.

The use case I saw for this was for a series of exceptions that
middleware classes could raise, which would then be handled by another
piece of middleware. As an example, my project has a bunch of
automatic authenticators - IP based, SAML based, crufty tokens
produced by Lotus Notes - but they failures in all of them should be
handled the same. Raising a generic exception in the appropriate
middleware, and then handling it in another middleware class seemed a
nice clean way of doing this, I was disappointed when I read
core/handlers/base.py

It wouldn't be tricky to change this so that exceptions raised from
middleware can be handled by middleware, but obviously this would be a
not inconsequential change in behaviour..

Thoughts?

Cheers

Tom

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.