Re: Perl port of the django template system.
On Tue, Dec 16, 2008 at 8:36 PM, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > > All of this is predicated on using the word "Django" in the name, which > is the bit I have a problem with. How is this different from, e.g., any of these? http://code.google.com/hosting/search?q=django- > Choose a different name for it. If you implement a web server in Perl > are you going to call it "Apache::*", if it does some of the same things > as Apache (e.g. using the HTTP protocol)? No, you're going to find a > proper name and then mention in the docs that it does some of the same > things as Apache, or in similar ways to Apache. That avoids any > confusion between your product and the actual Apache product. http://search.cpan.org/search?query=Apache=module Arien --~--~-~--~~~---~--~~ 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: Views returning data only
On Tue, Jul 15, 2008 at 9:10 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
> On Jul 15, 3:13 pm, Arien <[EMAIL PROTECTED]> wrote:
>> On Tue, Jul 15, 2008 at 7:34 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
>> > On Jul 15, 1:57 pm, Arien <[EMAIL PROTECTED]> wrote:
>> >> On Tue, Jul 15, 2008 at 5:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
[...]
> While a view cannot (should not) know the contents of the template
> used to serialize the content, loading a template named
> "whatever.html" couples it to an HTML Content-type. I does not make
> sense to serialize JSON data in a template named .html. I could of
> course use templates named "whatever.serializing_template" and use
>
> {% ifequal content_type "json" %}[1234,3452]{% else %}1234 p>3452{% endif %}
>
> in my template code but I think that looks butt-ugly. Also, how do I
> set the Content-type-header in a Template?
Why not pass the template and the Content-Type to the view? See
django.views.generic for examples of that approach.
>> >> Django is a *Web* framework. Views are the part of the framework that
>> >> generate responses to requests and both of those necessarily use HTTP.
>>
>> > A response-request paradigm is hardly unique to HTTP. Yes, Django is a
>> > web framework and yet, both models and templates are (naturally)
>> > decoupled from HTTP. The documentation even includes a paragraph about
>> > using templates in stand-alone mode!
>>
>> Sure, but that doesn't apply to views.
>
> Why not?
Views are your interface to the outside world, and since Django is a
Web framework that world speaks HTTP.
Arien
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Views returning data only
On Tue, Jul 15, 2008 at 8:20 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > I think your on to something here. However, we need to remember that > one of the great things about Django views is that they are just > python functions. ... or any other callable. Arien --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Views returning data only
On Tue, Jul 15, 2008 at 5:51 AM, vicvicvic <[EMAIL PROTECTED]> wrote: > An interesting effect of this whole thing is that it decouples views > from not only formatting but protocol. Django is a *Web* framework. Views are the part of the framework that generate responses to requests and both of those necessarily use HTTP. Arien --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Views returning data only
On Tue, Jul 15, 2008 at 5:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote: > > In the Django FAQ, we can read this about views: > >> In our interpretation of MVC, the "view" describes the data that gets >> presented to the user. It's not necessarily how the data looks, but which >> data is presented. The view describes which data you see, not how you see >> it. It's a subtle distinction. > > In my mind, "which data you see" would be equal to a context a view > returns, not the HttpResponse or the template. Why? Because rendering > a template is saying "I have this data and I want it presented the way > this template will present it". If the view is responsible for saying > that, it is at least partly responsible for telling us how we see the > data. If a view picks a template and renders it using some data, the template is still free to present the data any way it likes (with some Content-Type related restrictions). But you don't have to hard-wire the template (and the implicit Content-Type) in the view. Write a view that has (optional) arguments (with sensible defaults) for the template (and the Content-Type). > Right now, I have a couple of views which return some data. But I'm > also building another view, and I want the data from one of the first > views in this one. I can either duplicate the fetching from the first > one, or I can send an "internal" request and just get the dataset. I > pick WHICH data I want and add some to it. Or you could write a function that fetches and returns it, and use that function in both views. Arien --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Community representation
Can we get back to our regular program now and move personal problems to private communication, please? Thank you. Arien --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: FormWizard - GETs on all but last step?
On Tue, Jul 1, 2008 at 9:00 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 8:28 PM, Arien <[EMAIL PROTECTED]> wrote: >> >> On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: >>> >>> On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> Nice thing about GETs is that users aren't confronted with the dreaded >>>> "Data was submitted with POST" confirmation, which is confusing to >>>> most people and usually not tested. Basically you end up breaking the >>>> back button and the reload button. >>> >>> Um, this is intentional and a good thing. If you read the spec, not >>> only is the difference between GET and POST defined, but the way user >>> agents (browsers) should treat them is defined as well. Breaking the >>> back & reload buttons is a requirement of the spec to, among other >>> reasons, avoid multiple posts by impatient (or double-clicking) users. >>> Granted, browsers could provide more helpful messages, but we want >>> that behavior for POSTing data. >> >> What specification requires this? >> > A number of them actually. To name a few: > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9 > http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13 > http://www.w3.org/2001/tag/doc/whenToUseGet.html > > A decent summary of the issues are found here: > http://www.cs.tut.fi/~jkorpela/forms/methods.html Oh, right, now I see what you (and David Durham) are getting at when you say "breaking the back and reload buttons". It's this part of the HTTP spec: 9.1.1 Safe Methods [...] In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. I'll try and read more carefully next time. :-) Arien --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: FormWizard - GETs on all but last step?
On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. > <[EMAIL PROTECTED]> wrote: >> >> Nice thing about GETs is that users aren't confronted with the dreaded >> "Data was submitted with POST" confirmation, which is confusing to >> most people and usually not tested. Basically you end up breaking the >> back button and the reload button. > > Um, this is intentional and a good thing. If you read the spec, not > only is the difference between GET and POST defined, but the way user > agents (browsers) should treat them is defined as well. Breaking the > back & reload buttons is a requirement of the spec to, among other > reasons, avoid multiple posts by impatient (or double-clicking) users. > Granted, browsers could provide more helpful messages, but we want > that behavior for POSTing data. What specification requires this? > Which leads me to the question: In what use-case would a FormWizard > ever GET? GET is only to be used to retrieve data (i.e.: search > results) whereas POST should be used when submitting data to the > server. I can't think of any case where a multi-page form would be > used to "retrieve" data. I realize Jeremy suggested that POST would > still be used on the final page, but even so, the other pages > technically are still POSTing data. The other pages are obviously retrieving the form to be filled in to complete the next step. > Perhaps he wants to allow the user to stop part way through a wizard, > bookmark the url (with the data entered thus far preserved in the > querystring), and allow them to pick up where they left off later.? > Interesting, but I wouldn't recommend it. For one, that could result > in some long urls (perhaps even longer than the limit). A multi-part > form could add up to a lot pretty quick. Second, those would be some > ugly urls. And third, as mentioned above, it's not really the proper > use of GET anyway. I fail to see how the perceived beauty of the generated URLs matters? Depending on the situation, using GET for various pages of a wizard-style interaction may be exactly the right thing to do. This doesn't seem to mesh nicely with the way things work in FormWizard's world, though. Arien --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:07 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 13, 2008 at 12:02 PM, Arien <[EMAIL PROTECTED]> wrote: >> >> The non-English posts are clearly useful to the Django community as a >> whole, as it appears that the majority of its members don't speak >> English as their native tongue. > > I'm totally fine with non-English feeds being available. I didn't think you had any problem with them. >>> Having *only* a [language-agnostic] firehose feed, as we do now, is a >>> problem. >> >> Why? > > Because, as I've mentioned earlier: users effectively get noise in > their feeds. For any post in a language other than English, *the vast > majority* of the Django community won't be able to read it. I'm not > only talking about native English speakers here; why should we expect > that a native Portuguese speaker will be able to read a Russian post? Users will get noise in their feeds anyway: not everyone has the same interests, skills, etc. Seeing posts in a language you don't understand is the least of your problems, I'd think. ;-) Arien --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Queryset Refactoring: __nonzero__ for MySQL
On Thu, Mar 27, 2008 at 4:18 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Please note that psycopg2's cursor.execute() doesn't really respect > DB-API either, in the sense that .fetchone does actually fetch the > entire resultset into the python process unless the cursor is named, > i.e. connection.cursor is called with a name parameter. I was reminded of this when I read Malcolm's blog post yesterday. One correction to what you wrote: using an unnamed psycopg2 cursor, it is cursor.execute() and not .fetchXXX that will cause fetching the resultset into the python process. See for example <http://lists.initd.org/pipermail/psycopg/2007-January/005251.html> for more information. Arien --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
