I think you accidentally sent this to the wrong list. This is django-
developers, a mailing list for discussion about the development of
Django itself.
Thanks,
Eric Florenzano
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to thi
It seems like everyone's talking about two different things here:
1) Should Django add more apps to contrib?
2) Does staticfiles solve a real need that users of Django have
today? Is it the de-facto implementation of a common pattern?
Let's just drop the discussion of the first point for the pur
I agree that something like this is becoming more necessary, as I ran
into this a few days ago myself.
Funny how similar our strategies were (David's is more robust):
http://gist.github.com/629508
-Eric Florenzano
On Oct 19, 10:24 am, David Gouldin wrote:
> As client-side templates become more p
On Sep 25, 10:47 am, Carl Meyer wrote:
> The concept:
>
> We introduce the "virtual" model, which is an abstract model with the
> following additional characteristics:
I'm a fan of this implementation strategy, it's a much better solution
than the setting approach IMO.
Thanks,
Eric Florenzano
-
On Aug 4, 1:33 pm, Byron wrote:
> What are your thoughts on adding these implementations to core?
I think that the callable key function would fit well in core, and
debatably the flavor, version, and hashing stuff could fit well in
core too. I don't really think that the thundering herd protectio
The most flexible way is to be able to specify a callable that runs on
each cache key before it is sent to the server. Then it's just up to
Django to provide a sensible default callable, but people could
override it to provide one which matches their own requirements. This
is what I do in django-
Carl's proposal is exactly the kind of thing I was suggesting in my
first response to this thread (only better thought out and stated more
eloquently than I could have). Count me as a big +1 to it!
Thanks,
Eric Florenzano
--
You received this message because you are subscribed to the Google Grou
I'm glad to see that some serious thought is going into this issue!
This proposal sound very good (to me, at least) on the whole.
One thing that occurs to me, though, is that the people who are going
to want to customize form output are very frequently going to be the
people working mostly in the
On Apr 8, 12:32 pm, Waldemar Kornewald wrote:
> What I'm proposing is not a complete emulation of all features at all
> cost, but simply an automation of the things that are possible and in
> wide use on nonrel DBs. Moreover, you'd only use these features where
> actually needed, so this would be
On Apr 8, 10:50 am, Javier Guerra Giraldez wrote:
> A: use the _same_ ORM with NoSQL backends. then it's important to
> provide (almos) every capability of the current ORM, even if they have
> to be emulated when the backend doesn't provide it natively.
To do this would mean to essentially impl
I'm not really a developer on Django itself, but I am fairly
interested in non-relational databases, and some of the things being
said in this thread worry me a bit.
> 1. Nonrel DBs don't distinguish between INSERT and UPDATE
> On such DBs Model.save_base() shouldn't check if an entity already
> e
On Dec 30, 4:46 pm, James Bennett wrote:
> 1. How many filters are we talking about here? At the very least it
> seems like two: one for plain text and one for HTML (since you don't
> want tags or character entities getting chopped off partway).
Right now what's on the table with #5025 is a sing
I have a custom filter that does just this that I use in virtually
every single Django project I use. It's such a common pattern that it
seems almost silly not to have it included in core. It's also small
enough that it won't add much in the way of maintenance. Also, there
already exists a trunc
+1
On Oct 15, 10:45 am, Luke Plant wrote:
> Hi all,
>
> As a consequence of the proposed CSRF changes, we brought up wanting
> to add a shortcut like render_to_response that uses RequestContext, as
> a refinement, but didn't decide on anything. Ideally, we would have
> something as short as thi
If you ask me, a message queue sits quite firmly outside the realm of
what a web framework should be responsible for providing. I think you
are also underestimating the amount of effort and thought that goes
into writing a robust and scalable message queue. For one simple
example: what if Apache
> Actually, they call their package "dojox.dtl". Their documentation
> explains that it implements the Django template language.
Even still, at a local Python meetup a little over a month ago,
someone raised their hand and asked a question that went something
like this: "I saw that Django switche
On Nov 30, 9:51 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> * Django 1.1: JSON serialization looks for system json/simplejson
> first, fall back to django.utils.simplejson if not found and warn
> with PendingDeprecationWarning whenever django.utils.simplejson is
> used.
>
> * Django 1.2
17 matches
Mail list logo
