Re: localization in python code (views, models etc)

[Lachlan Musicman]

On Mon, Jul 11, 2011 at 21:02, stan  wrote:
>>
>> > class Book(models.Model):
>> >    title = models.CharField(max_length=120)
>> >    date_published = models.DateField()
>>
>> Big tip - if you *actually* need a date_published field, use a string :)
>
> Sorry, but I don't get it.
>
> You mean a CharField, right ?

Yah, sorry. I actually needed to write a "Books" app for some
translation data entry that needed doing at my local Uni - and Char
was plain easier for search and sort than Date - and very few books
have the month/day details - think about what you actually need the
date_published field for: search and sort and that's about it. You do
not need to do any maths with it. Use the Char.

cheers
L.


-- 
Schweigt stille, plaudert nicht (Be still, stop chattering) (aka The
Coffee Cantata) (BWV 211) is a secular cantatawritten by Johann
Sebastian Bach between 1732 and 1734. In a satirical commentary, the
cantata tells of an addiction to coffee, a pressing social problem in
eighteenth century Leipzig, where this work was premiered. (via
http://bestofwikipedia.tumblr.com/ )

-- 
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: Djangopeople.net status

[Russell Keith-Magee]

On Tue, Jul 12, 2011 at 7:00 AM, Bruno Renié  wrote:
> Hi fellow Django devs,
>
> I'd like to talk about a site that all of you probably know: djangopeople.net.
>
> The site has originally been developed by Simon Willison and Natalie
> Downe and is a very useful part of the different sites connecting the
> Django community. Recently, however, Simon and Natalie became too busy
> to handle the maintenance work and, with the site going down every now
> and then, people started to worry about its future. I read at some
> point that Simon had more or less agreed to let other people run the
> site, but there wasn't any volunteer I was aware of.
>
> Given that the source code is on github, we started with Dan Fairs and
> Filip Jukić to work on the codebase: updating to Django 1.3 and the
> practices and conventions that have emerged since 2009. This is still
> a work in progress but the result can be seen on the github repo:
> https://github.com/brutasse/djangopeople.net.
>
> At this year's EuroPython, we talked about this with Jannis, Andrew
> and Simon. The result of the chat was that Simon is willing to let the
> DSF run djangopeople.net as part of its infrastructure and the DSF now
> has a database dump of djangopeople.net. The idea is now to make this
> a more open project: with Dan and Filip, we haven't very much
> advertised our work since we were not sure where we were going. Now
> we'd like to help the DSF run the site and make it evolve with a very
> high bus factor.
>
> To that end, we'd love to hear from anyone willing to help us with the
> site, from writing code to suggesting new features and improvements.
> Maybe it could be interesting to team with the djangopeople.me crew as
> well :)
>
> Assuming the DSF lets us handle djangopeople.net, the next steps would
> be to get the data and load it on a django-frienly host (I have an
> ep.io app running the updated codebase). The purpose of this email is
> to make more official the fact that there's a group of people working
> on it, and that more group members are welcome :).

For the record -- if *anyone* has an idea for how to make the Django
community a better place, and is willing to put the time and effort
into making those ideas happen, the DSF will do anything it can to
help support them.

I'm really excited that Bruno, Dan and Filip et al have stepped up to
look after and improve Django People. I can't wait to see what nifty
new features you can come up with. Best of luck, and if you (or anyone
else) need anything that the DSF can help provide, don't hesitate to
ask.

Yours,
Russ Magee %-)

-- 
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: Form Rendering API Proposal

[Chris Beaven]

On Tuesday, July 12, 2011 4:17:08 AM UTC+12, Gregor Müllegger wrote:
>
> Hm, hidden fields are something that I have not taken into account after 
> our
> latest iteration. I think they are a bit special-cased and might need
> attention even if we drop changing-the-widget feature.
>
Agreed, it'd be nice to make this case work, and like you say, we have 
hidden_widget on the field already - just need a way to activate it (it's 
probably just as simple as a formconfig which changes the form field's 
widget attribute to hidden_widget).
 

> Your example is already achieveable without introducing a new template:
>
> {% form form using %}
> {% formconfig field with required=0 %}
> {% include "forms/p.html" %}
> {% endform %}
>
> This of course only works since you don't want to change actual markup from
> "forms/p.html". Otherwise you must define a new template.
>
Yeah, you're (both) right. I'm happy enough to see extends dropped for the 
sake of simplicity. It was me overthinking the situation.
And yes, since you've shown an advantage of the inline using, it makes sense 
to keep.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/AIW8SKA9tXgJ.
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.

Djangopeople.net status

[Bruno Renié]

Hi fellow Django devs,

I'd like to talk about a site that all of you probably know: djangopeople.net.

The site has originally been developed by Simon Willison and Natalie
Downe and is a very useful part of the different sites connecting the
Django community. Recently, however, Simon and Natalie became too busy
to handle the maintenance work and, with the site going down every now
and then, people started to worry about its future. I read at some
point that Simon had more or less agreed to let other people run the
site, but there wasn't any volunteer I was aware of.

Given that the source code is on github, we started with Dan Fairs and
Filip Jukić to work on the codebase: updating to Django 1.3 and the
practices and conventions that have emerged since 2009. This is still
a work in progress but the result can be seen on the github repo:
https://github.com/brutasse/djangopeople.net.

At this year's EuroPython, we talked about this with Jannis, Andrew
and Simon. The result of the chat was that Simon is willing to let the
DSF run djangopeople.net as part of its infrastructure and the DSF now
has a database dump of djangopeople.net. The idea is now to make this
a more open project: with Dan and Filip, we haven't very much
advertised our work since we were not sure where we were going. Now
we'd like to help the DSF run the site and make it evolve with a very
high bus factor.

To that end, we'd love to hear from anyone willing to help us with the
site, from writing code to suggesting new features and improvements.
Maybe it could be interesting to team with the djangopeople.me crew as
well :)

Assuming the DSF lets us handle djangopeople.net, the next steps would
be to get the data and load it on a django-frienly host (I have an
ep.io app running the updated codebase). The purpose of this email is
to make more official the fact that there's a group of people working
on it, and that more group members are welcome :).

Regards,
Bruno

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Chris, thanks Carl,

2011/7/9 Carl Meyer :
> Hi Chris,
>
> On 07/08/2011 04:00 PM, Chris Beaven wrote:
>> ...
>> I guess this means that rendering a field as "hidden" in the template is
>> also out, since this needs to modify more than just the field's
>> representation (specifically, non_field_errors).
>
> Yes. I mean, you're fully free to render a field as hidden yourself (via
> template), but anytime you make a change in the HTML that implies any
> change in server-side data handling, you're on your own to figure out
> the right solution for your case (which is no different than now).

Hm, hidden fields are something that I have not taken into account after our
latest iteration. I think they are a bit special-cased and might need
attention even if we drop changing-the-widget feature. I think it is also
technically something different than just exchanging widgets since any form
field is already aware about how it can be rendered with a hidden widget. That
also solves the don't-break-my-python-from-the-template issue since we only
use the hidden widget which is supported by the normal form field. See the
"hidden_widget" attributes:

https://code.djangoproject.com/browser/django/trunk/django/forms/fields.py#L45

> ...
>
>>     Now to your django-forms implementation that has the "extends"
>>     argument for
>>     the {% form %} tag. I still totally like the idea behind that, but
>>     like I
>>     already said in the other message -- it might be confusing to have two
>>     different meanings of the block tag. Carl has the same opinion here
>>     so we
>>     won't include that into our implementation.
>>
>> (Note that 'extends' also applies the formconfig, row and field tags too)
>>
>> I understand the potential for confusion, but I think it really does
>> bring something big to the table which is unfortunate to miss out on.
>> For example, if I just want to customize one field template on a form
>> then without this I have to redefine the whole form template.
>> It also allows for complex redefinition of a field's label and help text
>> without having to redefine the entire field template.
>
> Why would you otherwise have to redefine the whole form template? A form
> template is a normal template; you can put blocks in it and have another
> form template extend it and override those blocks. I don't think it's
> onerous (in fact, I think it's clearer and more maintainable) to do this
> in a separate file rather than "inline" as your proposal does. And I'm
> strongly in favor of reusing existing template language features and
> conventions rather than inventing new and confusing syntax for "inline
> extends"; IMO redefining the meaning of {% block %} contextually is
> simply a non-starter due to the extra difficulty in quickly
> comprehending template structure.
>
> AFAICT, your proposal doesn't actually bring any new capabilities to the
> table, it just lets you do the same thing inline rather than in a
> separate form template file that you reference with "using".
>
>> Here's real-life example off the top of my head we had the other day. A
>> client had a multi-step registration form. Usually, our rows show a *
>> next to the label of required fields but all of the first step was
>> required so the client didn't want the stars to show. I envision this
>> would look like this in django-forms (lets assume we've customised
>> 'forms/field/base.html' to conditionally conditionally change the label
>> class or just conditionally add the * after it):
>>
>> {% form form extends "forms/p.html" %}
>>     {% block config %}
>>         {% formconfig field with required=0 %}
>>     {% endblock %}
>> {% endform %}
>>
>> What would this look like with the current form proposal?
>
> You would just create a template "forms/p-no-stars.html" (or whatever)
> that {% extends "forms/p.html" %} and overrides the config block in the
> same way, and then you'd just say {% form form using
> "forms/p-no-stars.html" %}.

Your example is already achieveable without introducing a new template:

{% form form using %}
{% formconfig field with required=0 %}
{% include "forms/p.html" %}
{% endform %}

This of course only works since you don't want to change actual markup from
"forms/p.html". Otherwise you must define a new template.

And because the following examples are the same ...

{% form myform using "forms/p.html" %}
{% form myform using %}{% include "forms/p.html" %}{% endform %}

... is also my justification for having the second one ("using" inline)
directly in the GSoC scope. "extends" is IMHO something very different, like
Carl said, because it introduces a new idiom that is not already present in
the current features of the template language.

--
Servus,
Gregor Müllegger

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

Bizarre behaviour using django.test.client.Client.put

[Oliver Beattie]

Hi,

I don't really know if what I'm posting is expected behaviour or not (hence 
not going straight to Trac), but I am seeing very odd behaviour 
using django.test.client.Client.put.

The documentation 
describesthe
 put method as "acting just like Client.post()", but it seems this isn't 
really true at all. post() preserves data which has been encoded into the 
query string (and is documented to do so), but it seems that put() does not. 
It is nearly always overwritten by what the developer likely intended for 
the request body. Here's the offending 
code 
(please 
forgive the GitHub links).

The curious thing is this seems to have been implemented as a response to a 
ticket that I'm having trouble following, #11371 (a bit of a brain overload 
today).

Is this really intended behaviour?

—Oliver

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/XIee4lsJPNUJ.
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: localization in python code (views, models etc)

[Sergiy Kuzmenko]

On Mon, Jul 11, 2011 at 7:02 AM, stan  wrote:

>
>
> On Jul 11, 11:36 am, Lachlan Musicman  wrote:
> > On Mon, Jul 11, 2011 at 18:58, stan  wrote:
> > > Hi,
> >
> > > Maybe I missed something, but I didn't found any explanation in the
> > > doc about how to localize a date or a number in the python code side.
> > > Maybe I am totally wrong about wanting to do that but I can't see a
> > > solution to resolve the following problem in the template (where
> > > localization should be processed, I agree).
>

This sounds like django-users question and I believe the answer you are
looking for can be found here:
https://docs.djangoproject.com/en/1.3/topics/i18n/localization/#format-localization

-- 
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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[Dmitry Gladkov]

I don't see what's wrong with 'strip' attribute for models.Field,
we've already non database-related 'blank' attribute, but I agree that
it does not solve the general problem.

What I'm thinking about is something like django.core.validators [1],
but called 'processors' with the only and main difference that
processor returns value which gets passed to the next processor in
chain.

I'm not sure that it plays nice with existing clean_[fieldname]
methods and that 'processor' is a good name either, but I'd like to
hear what do you think about this idea.

Thanks.


[1] https://docs.djangoproject.com/en/dev/ref/forms/validation/#using-validators


--
Best wishes,
Dmitry Gladkov, mailto:dmitry.glad...@gmail.com

+380 91 303-37-46



On Mon, Jul 11, 2011 at 12:26 AM, Chris Beaven  wrote:
> To clarify, didn't even notice we were talking about models.Field, I'm +0
> for a 'strip' attribute on the form's field, nothing on the model.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/r9DLUCsK6rUJ.
> 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.
>

-- 
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: localization in python code (views, models etc)

[stan]

On Jul 11, 11:36 am, Lachlan Musicman  wrote:
> On Mon, Jul 11, 2011 at 18:58, stan  wrote:
> > Hi,
>
> > Maybe I missed something, but I didn't found any explanation in the
> > doc about how to localize a date or a number in the python code side.
> > Maybe I am totally wrong about wanting to do that but I can't see a
> > solution to resolve the following problem in the template (where
> > localization should be processed, I agree).
>
> > The typical use case is in the admin_list when you have a method in
> > list_display or MyModel.__unicode__() that return a string with a date
> > or a number. For example :
>
> > from django.utils.formats import localize
>
> > class Book(models.Model):
> >    title = models.CharField(max_length=120)
> >    date_published = models.DateField()
>
> Big tip - if you *actually* need a date_published field, use a string :)

Sorry, but I don't get it.

You mean a CharField, right ?


>
> I know I'm not answering the question, apols, but the kids are
> screaming for dinner etc.
>
> L.
>
>
>
>
>
>
>
>
>
> >    price = models.DecimalField(max_digits=8, decimal_places=2)
>
> >    def __unicode__(self):
> >        return u"%s - %s $" % (localize(self.date_published),
> > localize(self.price))
>
> > Is that usage discouraged and the reason for not being documented ?
>
> > If not, do I have to open a ticket with a path for this page :
> >https://docs.djangoproject.com/en/dev/topics/i18n/localization/?
>
> > Best regards.
>
> > --
> > 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 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> Schweigt stille, plaudert nicht (Be still, stop chattering) (aka The
> Coffee Cantata) (BWV 211) is a secular cantatawritten by Johann
> Sebastian Bach between 1732 and 1734. In a satirical commentary, the
> cantata tells of an addiction to coffee, a pressing social problem in
> eighteenth century Leipzig, where this work was premiered. 
> (viahttp://bestofwikipedia.tumblr.com/)

-- 
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: localization in python code (views, models etc)

[Lachlan Musicman]

On Mon, Jul 11, 2011 at 18:58, stan  wrote:
> Hi,
>
> Maybe I missed something, but I didn't found any explanation in the
> doc about how to localize a date or a number in the python code side.
> Maybe I am totally wrong about wanting to do that but I can't see a
> solution to resolve the following problem in the template (where
> localization should be processed, I agree).
>
> The typical use case is in the admin_list when you have a method in
> list_display or MyModel.__unicode__() that return a string with a date
> or a number. For example :
>
> from django.utils.formats import localize
>
> class Book(models.Model):
>    title = models.CharField(max_length=120)
>    date_published = models.DateField()

Big tip - if you *actually* need a date_published field, use a string :)

I know I'm not answering the question, apols, but the kids are
screaming for dinner etc.

L.


>    price = models.DecimalField(max_digits=8, decimal_places=2)
>
>    def __unicode__(self):
>        return u"%s - %s $" % (localize(self.date_published),
> localize(self.price))
>
>
> Is that usage discouraged and the reason for not being documented ?
>
> If not, do I have to open a ticket with a path for this page :
> https://docs.djangoproject.com/en/dev/topics/i18n/localization/ ?
>
> Best regards.
>
> --
> 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.
>
>



-- 
Schweigt stille, plaudert nicht (Be still, stop chattering) (aka The
Coffee Cantata) (BWV 211) is a secular cantatawritten by Johann
Sebastian Bach between 1732 and 1734. In a satirical commentary, the
cantata tells of an addiction to coffee, a pressing social problem in
eighteenth century Leipzig, where this work was premiered. (via
http://bestofwikipedia.tumblr.com/ )

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

localization in python code (views, models etc)

[stan]

Hi,

Maybe I missed something, but I didn't found any explanation in the
doc about how to localize a date or a number in the python code side.
Maybe I am totally wrong about wanting to do that but I can't see a
solution to resolve the following problem in the template (where
localization should be processed, I agree).

The typical use case is in the admin_list when you have a method in
list_display or MyModel.__unicode__() that return a string with a date
or a number. For example :

from django.utils.formats import localize

class Book(models.Model):
title = models.CharField(max_length=120)
date_published = models.DateField()
price = models.DecimalField(max_digits=8, decimal_places=2)

def __unicode__(self):
return u"%s - %s $" % (localize(self.date_published),
localize(self.price))


Is that usage discouraged and the reason for not being documented ?

If not, do I have to open a ticket with a path for this page :
https://docs.djangoproject.com/en/dev/topics/i18n/localization/ ?

Best regards.

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