Re: (Model)Forms localize=True violates DRY

2012-06-22 Thread Serge G. Spaolonzi
I have opened a ticked for this same issue, it was rejected because the
core team didn't liked the idea of including FormField options in
ModelField. Decision i think was correct, I wasnt aware the other
FormFields options in ModelFields like help_text were there for historical
reasons.
https://github.com/cobalys/django/blob/ticket_18471/django/db/models/fields/__init__.py

If this is not the correct way to do it, we need to find another way to do
it respecting the DRY principle.
imao the ModelFields must localize according to settings.USE_L10N, then if
it is specified in the option localize as false that field must not
localize.

>From the official Django Documentation:

USE_L10N
Default: False
A boolean that specifies if localized formatting of data will be enabled by
default or not. If this is set to True, e.g. Django will display numbers
and dates using the format of the current locale.


As I understand USE_L10N sets the default behavior application wise for the
localization.




Regards
Serge G. Spaolonzi



On Fri, Jun 22, 2012 at 9:16 AM, Karen Tracey  wrote:

> On Fri, Jun 22, 2012 at 7:23 AM, Klaas van Schelven <
> klaasvanschel...@gmail.com> wrote:
>
>> I've created a ticket, but have always understood that calling
>> attention to tickets should be done separately on the Django-
>> developers mailinglist
>
>
> It's not necessary nor encouraged to call attention to newly-opened
> tickets on the -developers list. People are asked to post to the list in
> preference to "contesting" a resolution the don't agree with (e.g.
> wontfix). Newly-opened tickets on the other hand don't need to be announced
> on the list, plenty of people monitor the flow of incoming tickets.
>
> Karen
>
>  --
> 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.



Re: Reg Memcache issue.

2012-06-22 Thread Luke Plant

On 22/06/12 19:08, Ramesh-Nivista wrote:
> Hi,
> 
> We are facing one issue when we tried to update the memcache module.
> Please check below our issue which is explained indetail.
> 
> 
> We tried to deploy our django application and whenever we access a
> particular content based page( a page which fetches the data from DB)
> we are facing cache time out error.
> 
> We are facing this error when @cache_ananonymous decorator is called
> in memcache.py file. It says cache_timeout argument missing.

If you are having a problem with Django, the place to ask is the
django-users list, or file a ticket on our Trac instance
(code.djangoproject.com) if you think you've found a bug in Django

BTW, there is no cache_anonymous decorator in Django, so it is likely
your problem is elsewhere.

Thanks,

Luke


-- 
Parenthetical remarks (however relevant) are unnecessary

Luke Plant || http://lukeplant.me.uk/

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



Reg Memcache issue.

2012-06-22 Thread Ramesh-Nivista
Hi,

We are facing one issue when we tried to update the memcache module.
Please check below our issue which is explained indetail.


We tried to deploy our django application and whenever we access a
particular content based page( a page which fetches the data from DB)
we are facing cache time out error.

We are facing this error when @cache_ananonymous decorator is called
in memcache.py file. It says cache_timeout argument missing.

We enabled the following modules also in django settings file :

django.middleware.cache.UpdateCacheMiddleware
django.middleware.cache.FetchFromCacheMiddleware
 AuthenticationMiddleware.


Our settings file is configured with the below lines:

CACHE_BACKEND=memcache://127.0.0.1:11211


Please advice how to resolve this issue.

-- 
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: (Model)Forms localize=True violates DRY

2012-06-22 Thread Karen Tracey
On Fri, Jun 22, 2012 at 7:23 AM, Klaas van Schelven <
klaasvanschel...@gmail.com> wrote:

> I've created a ticket, but have always understood that calling
> attention to tickets should be done separately on the Django-
> developers mailinglist


It's not necessary nor encouraged to call attention to newly-opened tickets
on the -developers list. People are asked to post to the list in preference
to "contesting" a resolution the don't agree with (e.g. wontfix).
Newly-opened tickets on the other hand don't need to be announced on the
list, plenty of people monitor the flow of incoming tickets.

Karen

-- 
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: Plans for "forms"

2012-06-22 Thread Klaas van Schelven
Thanks for the info

On Jun 21, 2:04 pm, Andrew Godwin  wrote:
> On 21/06/12 11:58, Klaas van Schelven wrote:
>
> > Hi all,
>
> > I'm not entirely sure about the forum to ask this question: the
> > motivation is "django-users" like; but since it's about a roadmap /
> > the future I suppose only developers will know the answer.
>
> > I vaguely remember there being mention of big plans to do a big
> > refactoring of Django's forms/modelforms/formsets functionalities at
> > DjangoCon EU 2011. I'm not entirely sure what these plans entailed, if
> > there were ever such plans or if they've already been implemented. If
> > anything is surely to come up for Django 1.5 we'll postpone some
> > refactorings in our own code untill we know what the new canonical way
> > of doing this is.
>
> Hi Klaas,
>
> I suspect you're thinking of the form templating refactor (making all
> the form widgets use templates that can be overridden etc.) - this was
> done for GSOC last year but unfortunately it's blocked on us improving
> the template engine - it's too slow in the current one to be workable.
>
> There was also a GSOC project that same year to make the templating
> faster, but that unfortunately didn't result in something we could use.
>
> Andrew

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



(Model)Forms localize=True violates DRY

2012-06-22 Thread Klaas van Schelven
Hi all,

I've created a ticket, but have always understood that calling
attention to tickets should be done separately on the Django-
developers mailinglist, so allow me to copy/paste a bit:

As it is now one cannot make localized ModelForms without violating
DRY. Developers w/o the desire for localized data in their application
can simply take a model and then create a modelform in three lines and
an admin interface in even less. However, a developer that wants
localization to work in the admin/their modelforms needs to set the
attribute localize=True for each single field that they want
localized. This breaks DRY as there is both repetition of the
"localize=True" and it also introduces new repetition between models &
their forms.

I understand that the decision to make localize=False the default was
both deliberate and probably the correct one, as Russel explains
here:  
http://groups.google.com/group/django-developers/browse_thread/thread/01096cd968bf276a/9ad982e939f1284f

However, a couple of notes:
* I think the case Russel mentions is the exception, not the rule.
"Usually" a number is just a number, not a year. Postal codes and
phone numbers are often not numbers at all.
* We (Django) have made the opposite decision for template rendering:
Indicating USE_L10N in settings makes localized rendering the default
throughout the application, and the developer is left to find the
exceptions and note them whenever they occur. This is inconsistent
with the way we deal with forms (and has the usual drawbacks of
inconsistency, such as the confusion of the OP in the email above).

My suggested solution would be to add an attribute to ModelFields.

We already have a number of cases in which attributes of models'
fields are propagated to your modelforms. blank => not required,
verbose_name => label and help_text => help_text spring to mind.

I'd say name this attribute "localize" and default it to True (since
that's the most common case). But this will introduce backwards
breakage, so I can also imagine simply keeping it False as a default.
That would at least get rid of the violation of DRY mentioned above.
Alternatively the default value of this attribute could be
settings.USE_L10N.

Once we have localize=True/False on modelfields, we could even
envision using that value in template output as well, i.e. years will
automatically be recognized as such and we no longer need to
explicitly mark them as non-localized each time they're used in a
template. But maybe that's ground for another ticket.


regards,
Klaas van Schelven

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