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

2011-09-04 Thread Reinout van Rees 

On 04-09-11 21:28, Reinout van Rees wrote:

On the other hand, from an object oriented viewpoint, the class based
views seem to be pretty powerless and non-object-oriented. To me, it
almost seems like they're artificially "castrated" to make function
views look good :-) That's probably not the intention, but...


Ehm, the current classes based views are pretty good, apart from the 
view-not-in-context problem that I see.


That's the one point on which I find those CBV's to be somewhat powerless.

Upon re-reading it sounded a bit like I think the whole of class based 
views is powerless and bad, but that was *totally* not my intention :-) 
I love 'em :-)




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.

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

2011-09-04 Thread Reinout van Rees 

On 03-09-11 16:05, Luke Plant wrote:

The history of CBVs in Django is that they are simply a way of using OOP
and inheritance to reduce duplication between view functions and allow
better re-use. They are supposed to be drop in replacements for function
based views in terms of the end result, rather than produce any change
in what a template will contain.


Ok, when you want to keep the function and class based views more or 
less the same, the current implementation makes sense.


On the other hand, from an object oriented viewpoint, the class based 
views seem to be pretty powerless and non-object-oriented. To me, it 
almost seems like they're artificially "castrated" to make function 
views look good :-) That's probably not the intention, but...


Probably the best illustration of my point: .get_context_data() should 
return a dictionary. And .render_to_response() needs the output of that. 
"So" you have to pass the output of .get_context_data() to 
.render_to_response(). Wait a minute... We're talking object orientation 
here! Why doesn't .render_to_response() call .get_context_data()? This 
is just function-like behaviour in a thin object oriented shell.


From an OO viewpoint, I'd rather expect a "self.context = {}" in the 
most top-level view baseclass's __init__(). Not passing along a variable 
that is calculated in the very same class as a parameter to a method in 
that very same class.



Your point that, effectively, {{ view.something }} is different than {{ 
something}} is valid, though. In that sense, a class based view that 
passes {'view': self} as the context dict isn't a drop-in replacement.


Would you be more happy with a more magical view that would inject 
everything from local() into the context dictionary or something like that?



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.

Re: Multiple timezone support for datetime representation

2011-09-04 Thread Daniel Swarbrick 
I'm wholeheartedly on +1 on this.

@Anssi Kääriäinen, re your localtime meeting example: this type of
scenario has been discussed on this list previously, and the generally
acknowledged solution is to use separate date and time fields, neither
of which (on their own) have a concept of timezone.

@Aymeric Augustin, re storing UTC in Postgres: this is somewhat moot,
since Postgres stores timestamps internally as a UTC Julian date
regardless of which timezone the client connection uses (client TZ
offset is dynamically added/subtracted at insert/update/select-time).
In the case of MySQL and SQLite however, it is a valid point.

I can understand some people's concerns about the dependency
requirement of pytz in order to achieve this. It would have been great
to see pytz added to the standard Python libs in 3.x, since (IMHO)
it's such a fundamental requirement of any language these days. In any
case, it will be great to see Django's international date/time
handling be on a par with its L10N and I18N features.

On Sep 4, 12:48 am, Mikhail Korobov  wrote:
> Great job on summarizing the issue!
>
> I have one concern though. Can you please explain why is USE_TZ option
> better than introducing e.g. UtcDateTimeField?
>
> USE_TZ=True will break all existing code (including external apps) which
> relies on django 1.3 documented DateTimeField behavior, this can be scary
> and will introduce a lot of "if getattr(settings, USE_TZ, False): #..."
> statements in external apps for backwards compatibility.
>
> Good UtcDateTimeField implementation can be released as a separate package
> (and then eventually included in django itself). This way existing django
> projects will be able to use it without waiting for a release and backwards
> compatibility won't be broken. Are there obstacles in django itself that
> prevent this option?

-- 
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.