Re: localization in python code (views, models etc)
On 12 Jul 2011 01:22, "Lachlan Musicman" wrote: > > 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. Why would you use a CharField for a date column? This is extremely bad practise. You'd just simply use a DateField, then default to the 'first available value' for missing fields in the date. For exampme, June 2010 would become 2011/06/01 00:00:00. Unless you have a good reason not to use datefield..? > > 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. > -- 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.
[GSoC composite fields] Weekly check-in #7
Basic support in the admin is now working: adding, editing and deleting single instances with composite primary keys. Obviously, there's no inline support yet since relationship fields are not yet ready. Michal [1] https://github.com/konk/django signature.asc Description: Digital signature
Re: localization in python code (views, models etc)
On 11.07.2011, at 10: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() >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/ ? Yeah, django.utils.formats.localize is the main function to localize a value using the format localization engine from Python. The missing documentation is a bug, IMO. Jannis -- 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)
On Jul 12, 12:28 pm, Jannis Leidel wrote: > Yeah, django.utils.formats.localize is the main function to localize > a value using the format localization engine from Python. The missing > documentation is a bug, IMO. Just a minor correction: localize does not use the localization engine from Python, it uses Django's inbuilt localization. Python's localization can't be trusted to be thread-safe (although on some platforms it probably is). This is not a big point, except that the inbuilt localization engine is slower than Python's. One is written in Python, the other uses system libraries written in C. - Anssi -- 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)
On 12.07.2011, at 12:15, akaariai wrote: > On Jul 12, 12:28 pm, Jannis Leidel wrote: >> Yeah, django.utils.formats.localize is the main function to localize >> a value using the format localization engine from Python. The missing >> documentation is a bug, IMO. > > Just a minor correction: localize does not use the localization engine > from Python, it uses Django's inbuilt localization. Python's > localization can't be trusted to be thread-safe (although on some > platforms it probably is). This is not a big point, except that the > inbuilt localization engine is slower than Python's. One is written in > Python, the other uses system libraries written in C. Thanks, you're right. I meant to say: django.utils.formats.localize is the function you can use to localize a value using *Django's* format localization engine *in your Python code*. English-as-a-second-language'ly yours, Jannis -- 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
Hi Dmitry, I think we could have combination of "validators" + "processors": they will return either exception or cleaned value. For example, SomeField(cleaners=[clean_and_validate_email()]) Did you mean exactly this or rather separated SomeField(validators=[...], processors=[...]) ? On Mon, Jul 11, 2011 at 6:31 PM, Dmitry Gladkov wrote: > 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. > > -- Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
Hi Yuri, At first I thought that we should extend validators logic, but then I realized that validation and cleaning (agree that 'cleaners' is a better term than 'processors') are rather different tasks and mixing them could be ambiguous, not mentioning backwards incompatibile as a cleaner should return a value whether a validator should not. -- Best wishes, Dmitry Gladkov, mailto:dmitry.glad...@gmail.com +380 91 303-37-46 On Tue, Jul 12, 2011 at 2:09 PM, burc...@gmail.com wrote: > Hi Dmitry, > I think we could have combination of "validators" + "processors": > they will return either exception or cleaned value. > For example, > SomeField(cleaners=[clean_and_validate_email()]) > Did you mean exactly this or rather separated SomeField(validators=[...], > processors=[...]) ? > On Mon, Jul 11, 2011 at 6:31 PM, Dmitry Gladkov > wrote: >> >> 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. >> > > > > -- > Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.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. > -- 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.
django.contrib.comments - No reference to commented object in preview
Hi there,
why there is no reference to commented object in preview?
django/contrib/comments/views/comments.py:95
return render_to_response(
template_list, {
"comment" : form.data.get("comment", ""),
"form" : form,
"next": next,
},
RequestContext(request, {})
)
It would be nice to have "object" variable with commented object.
Views knows about it using content type and pk. Thanks to lazy
evaluations of querysets, there won't be any hits to database unless
necessary.
--
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: django.contrib.comments - No reference to commented object in preview
Hi,
On Jul 13, 1:42 am, Tomáš Ehrlich wrote:
> Hi there,
> why there is no reference to commented object in preview?
>
Any specific use-case? Specifying it can make it easier to decide.
> django/contrib/comments/views/comments.py:95
> return render_to_response(
> template_list, {
> "comment" : form.data.get("comment", ""),
> "form" : form,
> "next": next,
> },
> RequestContext(request, {})
> )
>
The line of thinking was that preview would perform form-level
validation and the model-level validation (that of checking for
duplicates etc) would be done on save.
> It would be nice to have "object" variable with commented object.
> Views knows about it using content type and pk. Thanks to lazy
> evaluations of querysets, there won't be any hits to database unless
> necessary.
There would be one query, that for checking duplicate comments if the
object is sent through the context.
I think this is a valid request to open a ticket and marked as DDN so
that the core team may decide.
--
Cheers
Theju
--
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: django.contrib.comments - No reference to commented object in preview
Hi there,
the reason is I want to show commented object (or some parts of it)
during preview or correcting errors. I saw this behavior on lots of
sites.
Rewriting whole method because of one line seems like overkill to me.
Ticket:
https://code.djangoproject.com/ticket/16456
On 13 čnc, 07:22, Thejaswi Puthraya
wrote:
> Hi,
>
> On Jul 13, 1:42 am, Tomáš Ehrlich wrote:
>
> > Hi there,
> > why there is no reference to commented object in preview?
>
> Any specific use-case? Specifying it can make it easier to decide.
>
> > django/contrib/comments/views/comments.py:95
> > return render_to_response(
> > template_list, {
> > "comment" : form.data.get("comment", ""),
> > "form" : form,
> > "next": next,
> > },
> > RequestContext(request, {})
> > )
>
> The line of thinking was that preview would perform form-level
> validation and the model-level validation (that of checking for
> duplicates etc) would be done on save.
>
> > It would be nice to have "object" variable with commented object.
> > Views knows about it using content type and pk. Thanks to lazy
> > evaluations of querysets, there won't be any hits to database unless
> > necessary.
>
> There would be one query, that for checking duplicate comments if the
> object is sent through the context.
>
> I think this is a valid request to open a ticket and marked as DDN so
> that the core team may decide.
>
> --
> Cheers
> Theju
--
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.
