On Jan 4, 8:46 pm, Waylan Limberg wrote:
> That being said, it does strike me as being a little odd that there is
> no way to validate your data when using create() or get_or_create().
> In fact, the docs [1] describe both those methods as shortcuts. But if
> you're writing an app that always need
Hey Alex,
thanks for taking the time to review the code. However, we've agreed not to
construct the app instances in the settings.py file as it would require
imports to be used, and stick to the convention of dotted paths. You might
want to read this thread [0], but especially this [1] reply from
On 4 Jan 2011, at 20:15, Nils Fredrik Gjerull wrote:
>
> Hi, Django folks!
>
> This is my first time posting on the Django developer list. Thanks for
> an amazing framework.
>
> The Distribute build system supports namespaced packages
> (http://packages.python.org/distribute/setuptools.html#name
I guess, we found a bug, not sure if it has been reported earlier and
whether this is the right place to report.
When a template contains translations in variables, like
{{ _("text") }}, the text seems to be translated already during the
creation of the Template object. Every following call of
Tem
See also: http://pastebin.com/Wstya2C6
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@goo
Hi all,
As I just noted on a blog entry, I've tagged the 1.3 release blocking
bugs in Trac:
http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&keywords=%7Eblocker
Most of these are fairly minor issues. However, there are 5 tickets
that are regressions from 1.2.3 to 1.
Does anyone know how to create a Django installer for Installatron?
I've two cheap providers and they both use Installatron. It would be
great to start a Django project that way. I happen to hate the
terminal, command line and other installers that waste a lot of
time ;-)
Thanx!
--
You received
Hi all,
Ticket #15012 highlights that you can't use a cache_page decorators on
pages that return a TemplateResponse. The problem goes like this:
* A decorator operates on the output of a function
* cache_page stores the output of a function so it can be used in the
future instead of invoking th
This is the Django Mailinglist for Developers, for Questions about using
Django please ask at Django Users
Am 05.01.2011 17:20 schrieb "Martijn" :
Does anyone know how to create a Django installer for Installatron?
I've two cheap providers and they both use Installatron. It would be
great to star
on., 05.01.2011 kl. 09.32 +0800, skrev Russell Keith-Magee:
> A similar request was made in ticket #14087. I closed that ticket as
> wontfix because allowing multiple applications with the same name is
> fundamentally problematic; however, you have highlighted that that
> this problem isn't tied to
Hi,
Option (5) sounds great; but if you want backwards compat option (1)
is the only way to go. cache_page isn't the only decorator affected by
this problem; I could imagine there are many decorators in 3rd party
apps which try to alter the response. So the question is how much code
will we break
On Thu, Jan 6, 2011 at 4:48 AM, Florian Apolloner wrote:
> Hi,
>
> Option (5) sounds great; but if you want backwards compat option (1)
> is the only way to go. cache_page isn't the only decorator affected by
> this problem; I could imagine there are many decorators in 3rd party
> apps which try t
On Wed, Jan 5, 2011 at 12:21 PM, Jonathan S wrote:
> I guess, we found a bug, not sure if it has been reported earlier and
> whether this is the right place to report.
>
> When a template contains translations in variables, like
> {{ _("text") }}, the text seems to be translated already during the
Hi,
On Jan 6, 12:02 am, Russell Keith-Magee
wrote:
> There are no backwards compatibility concerns here. We're talking
> about the class-based generic TemplateView.
Sorry, I just noticed now, that the current function based views are
still function based and not wrappers around the class based v
On Wed, Jan 5, 2011 at 5:41 PM, Florian Apolloner wrote:
> Hi,
>
> On Jan 6, 12:02 am, Russell Keith-Magee
> wrote:
> > There are no backwards compatibility concerns here. We're talking
> > about the class-based generic TemplateView.
>
> Sorry, I just noticed now, that the current function based
So for the sake of the argument I've changed the template code to use
"{% load i18n %}" and also added a filter, since that is our use-case.
http://dpaste.com/294778/
I thought that if you wanted to apply a filter to a string in a
template that you had to use _ instead of {% trans %}.
-- Gert
Mo
16 matches
Mail list logo