Correct me if I’m wrong, but won’t the inlines display the actual
relationship that you
On Aug 14, 5:43 pm, smcoll wrote:
> Currently, we can override the queryset used by ModelAdmins. This is
> helpful, since often times the default manager omits instances that
> nevertheless belong in the adm
...would get via the actual Python API? In this case, you couldn’t
switch the managers around either.
On Aug 15, 10:19 am, Zachary Voase
wrote:
> Correct me if I’m wrong, but won’t the inlines display the actual
> relationship that you
>
> On Aug 14, 5:43 pm, smcoll wrote:
>
&g
Hi Andi,
On 21 Aug 2009, at 05:34, Andi Albrecht wrote:
> Hi,
>
> I'm interested in working on #10355 "Add support for email backends."
>
> IMHO it's an good idea to make the email backend configurable. There
> are at least two use cases I can think of. The first is to send email
> with other se
On 21 Aug 2009, at 11:39, Tim Chase wrote:
> Having email settings defined globally precludes the ability to
> do things like create a web email application for which each user
> has their own email (usually SMTP/IMAP/POP) settings. While yes,
> I could see having some defaults at the settings.p
I’d like to point you to http://code.zacharyvoase.com/urlobject/.
You can include as much information in a URL as you like, and it's a
subclass of unicode, so it can be used directly in templates, HTTP
clients, et cetera.
You can do stuff like URLObject(host='hostname', path='/foo/bar/'), or
Looking back at my previous post it seems like I'm being aggressive or
something. Sorry about that, that's 36 hours worth of sleep
deprivation for you :)
OK, so I think I've roughed together an idea of how you might use
URLObject in url() methods (or get_url(), or __url__(), et cetera).
You can s
If you take a look, you’ll notice that URLObject, being a subclass of
unicode, can be used *directly* within the template and it'll render
out to the URL without any magic.
In addition, you can ensure that the URLObject is host-relative by
doing `url.without_host()` (or {{ url.without_host
(), which are tiny wrappers over add_query_param() and set_query_param
() respectively.
--
Zack
On 13 Sep 2009, at 18:59, Ivan Sagalaev wrote:
>
> Zachary Voase wrote:
>> If you take a look, you’ll notice that URLObject, being a subclass of
>> unicode, can be used *directly* withi
On 11 Oct 2009, at 16:09, Alex Gaynor wrote:
> I don't want to be overly negative, but in my view rewriting the
> tutorial would be a pointless waste of energy. It has served us
> exceptionally well over the past 4 years, and none of the problems
> with it are fundamental, we'd be far better ser
On 11 Oct 2009, at 23:39, Joshua Russo wrote:
> How about the possibility of an advanced tutorial, to highlight more
> advanced features.
That's pretty much what the Django Book is for.
--
Zack
--~--~-~--~~~---~--~~
You received this message because you are s
Just wanted to add my $0.02; I’ve created a class-based views system
for Django, which you can find at http://github.com/zacharyvoase/django-clsview
(skip down to 'Examples' to see it in action).
It solves the thread-safety problem, decoration is easy, pointing to
views from the URLconf is trivial
At the moment it's very easy to add methods to individual models, just
by putting a method on the model class itself which accepts 'self'.
However, defining business logic on collections of records is
currently pretty complicated — you have to create at least a custom
Manager subclass, and if you w
On Jan 3, 7:01 am, Russell Keith-Magee
wrote:
> On Tue, Jan 3, 2012 at 1:55 PM, Zachary Voase wrote:
> > At the moment it's very easy to add methods to individual models, just
> > by putting a method on the model class itself which accepts 'self'.
> >
It should be relatively simple to allow QuerySets to know which
manager they came from, and then override __getattr__ to use the
declared @querymethod from that manager (instead of the other way
around). This avoids the unpickleable QuerySet subclass problem.
On Jan 10, 8:54 am, Anssi Kääriäinen
I strongly feel that switching around managers like that would be an
example of overengineering.
The user story which drove this RFC was based on an issue which has
been encountered by lots of developers, but typically solved in a
single way. Django's conservative style of development is very
acco
I spoke about this on here a while ago, but seeing as the 1.1 feature
freeze is looming, I thought it would be a good idea if I brought it
up again.
I think it's a good idea to have some support for using Python's
decorator syntax on signal receivers; seeing as Django's probably
going to switch t
Don't forget, a lot of people also use a custom method of deletion on
their models; they may not want to remove a record from the database,
but instead set a 'deleted' flag; having deletion also there by
default means they would have two deletion actions. I'd say that
deletion should be there if n
Hi Developers,
I know this feature request might be a little late in the
development process, so I’m sorry about that. The idea is to add a
reload() method to SessionBase, so that the session data can be
reloaded from it’s storage backend at any point during the view
processing. The motivation
I just found out that a particular Django ORM trick [1] seems to work
just fine but is undocumented.
Could I ask what the official status is with regards to this ‘trick’?
Is it intentional? Also, since there isn’t any documentation for it,
if it is in fact an intended feature, would you like me t
19 matches
Mail list logo
