On Jan 13, 10:23 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I think
> Chris's idea misses a bunch of the subtleties (and that isn't a
> criticism of him writing the proposal, since he has laid out his point
> of view clearly and offered a solution without any fuss, rather than
> continual
On Jan 13, 6:26 pm, "Gil Pinheiro" <[EMAIL PROTECTED]> wrote:
> MEDIA_* is poorly named since they overload the meaning of 'media'
> which otherwise relates back to the static css/img/js content.
> MEDIA_UPLOAD, or something else would be clearer. If this is not
> changed then the description need
It has always frustrated me that email addresses are just given away to
spammers. Is there anything that can be done to hide or obscure
commenter/submitter emails and "CC" emails?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
Granted, Jan, but a human still had to sign up their spam bot.
In the case of the web site, all the email addresses publicly
accessible to any and every spam-spider. It's just not good etiquette.
--~--~-~--~~~---~--~~
You received this message because you are su
On Jan 19, 11:24 am, Michael Radziej <[EMAIL PROTECTED]> wrote:
IMHO, it shouldn't go into stage "Needs Decision" before the
information arrives.
I'm not a fan of instantly closing tickets while waiting for
information but I see the point Jacob/Micheal is expressing.
It would be great to have
Done, but can't submit it.
On Jan 20, 6:27 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
On 1/18/07, telenieko <[EMAIL PROTECTED]> wrote:
> I was writting a document for Django's documentation (#3325) and just
> noticed that links between documents of the documentation are absolute, is
> th
Trying to upload diff:
akismet spam error (too many links)
Trying to upload tar of the same:
TypeError: PgQuoteString() argument 1 must be string without null
bytes, not str
On Jan 20, 8:32 am, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
On 1/19/07 1:01 PM, SmileyChris wrote:
>
On Jan 19, 2:29 am, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > (At least, I cannot reopen from closed/invalid)
> Very interesting - it looks like that action is being hidden from
> non-authenticated users... I'll investigate.
How's the investigation going? I'm apprehensive of closing ticket
Deletion of objects with a GenericRelation(X) deletes unrelated X
objects with the same object_id!
http://code.djangoproject.com/ticket/3215
This ticket needs developers focus sooner rather than later. The
implications of this patch mean it's not acceptable for this patch to
sit in the queue - it
> I wish there were a way for Google Groups moderators to allow other
> trusted users to OK the spam messages, because clearly this is a
> bottleneck. If there is, please let me know.
There is. Go to "Management Tasks", "Manage Members"
Then find the members you trust, and promote them to "manage
I'd suggest doing it as middleware which appends to the request (sorta
like the user middleware). This way it's available in the view as well
as the template context (if you pass it explicitly or use the request
context processor).
Also, what about urls.py deeper than just parent->child? Maybe st
Thanks Jacob!
On Feb 7, 5:29 am, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Howdy folks --
>
> SSIA; sorry about the bug!
>
> Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
Hi Rob, there's similar functionality in Django already (but it's
undocumented afaik) using a custom data structure called
DotExpandedDict:
http://code.djangoproject.com/browser/django/trunk/django/utils/datastructures.py#L215
I just opened a ticket regarding it's undocumented nature.
--~--~---
On Feb 10, 1:41 pm, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Interesting. I'm guessing it's not wired up to request.POST... I tried
> naming my form like name="name.key" and got no DotExpandedDict love. :)
You'd just do the following line:
post = DotExpandedDict(request.POST)
then you'll have s
On Feb 18, 10:10 pm, "Arnaud Delobelle" <[EMAIL PROTECTED]>
wrote:
> > However - I acknowledge the use case: Two lists, n items long, that
> > are from independent sources. I think a separate template tag in the
> > same vein as {% regroup %} would be a better approach.
>
> > {% zip lista list
It does seem a bit strange that Adrian says he's never needed to use
this. Apart from hard-coding links to your media, am I missing
something obvious?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develope
On Feb 20, 2:30 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> But I suppose that you are talking about using MEDIA_URL to access CSS
> and JS files, right? If yes then it's not what everyone does. Many
> people keep CSS and JS under source control in a place that has nothing
> to do with a direct
On Feb 22, 7:48 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> I know Adrian's argued that this is feature creep, but in this
> particular case I'm not convinced.
Thanks for chiming in James, your reasons are the ones I've been
trying to iterate.
Regarding ADMIN_MEDIA_PREFIX however there is al
On Mar 2, 11:31 am, "Rubic" <[EMAIL PROTECTED]> wrote:
> One possibility would be to allow max_length to be
> used as a maxlength attribute so applications could
> begin to future-proof.
The patch for this is waiting for checkin (minus Honza's suggestion of
a depreciation note)
http://code.django
Anton Khalikov opened a new ticket pointing out a hole in the current
session framework which can cause session id collisions.
He's put together a newsessions package which could be good, but
obviously needs some discussion (here). So, discuss away!
http://code.djangoproject.com/ticket/3716
--
On Mar 21, 5:27 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Brad Fults <[EMAIL PROTECTED]> wrote:
>
> > Is there a specific reason that newforms' Fields are using an
> > inconsistent name? If not, I suggest that these all be normalized to
> > "maxlength" and "minlength".
>
> Act
On Mar 21, 9:03 am, "Brad Fults" <[EMAIL PROTECTED]> wrote:
> Though, now I'm concerned that max_length on the Field is different
> from maxlength (the HTML attribute) on the Widget, which are
> frequently specified *right next to* one another. This seems
> undesirable.
It's not that "frequent" t
On Mar 24, 7:37 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Just an idea, but maybe someone could make a new field class that
> encapsulates a hidden HTML input element (hidden by style) that has no
> label, and the developer can name it something conspicuous (like
> `email`). The end re
On Mar 23, 10:46 pm, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote:
> But the original poster gave me this idea: would it be useful to have a
> field which specifically disallows auto-complete. May be an optional
> argument for CharField? [HTML allows to do a autocomplete=off in input
> fields].
You
For a while I've been thinking that it would be nice to have a tag so
you could re-use an expression in a template.
I did one up and put it on http://www.djangosnippets.org/snippets/132/
Is this useful enough for core?
--~--~-~--~~~---~--~~
You received this mess
On Mar 25, 8:00 am, "Aidas Bendoraitis" <[EMAIL PROTECTED]>
wrote:
> Wouldn't it be more convenient not to have the closing {% endwith %}?
Perhaps, but rather than "dirtying" up the context, this keeps the
variable nice and encapsulated.
> On 3/24/07, Baptiste <[EMAIL PROTECTED]> wrote:
> > Fo
On Mar 26, 2:00 am, Norman Harman <[EMAIL PROTECTED]> wrote:
> Is this the "django" way to go about solving these issues,esp strip() in
> save() or formField
> Are these being worked on somewhere?
> Are these things people would want in django (as opposed to everyone
> making their own version)?
And just to make it clear, the main point of this patch is so that
templates can benefit from the internal caching going on. Such as:
{% for product in products %}
{{ product }}
{% with product.purchases.count as purchases %}({{ purchases }}
purchase{{ purchases|pluralize }}){% endwith %}
{% endf
On Mar 27, 3:07 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Chris: can you work up a patch in case we decide to check this in?
Sure: http://code.djangoproject.com/ticket/3826
--~--~-~--~~~---~--~~
You received this message because you are subscribed to t
On Mar 28, 9:03 am, "vfoley" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I rewrote the forms portion of an application by using newforms. It's
> pretty nice, however there is something extremely annoying: newforms
> automatically adds a colon after labels (hopefully, my formatting is
> correct):
Thi
Can a core developer please check in the missing file from the ticket
(it's in the patch, it just wasn't committed it seems):
http://code.djangoproject.com/ticket/3799
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On Mar 28, 9:57 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> I've done some thinking on this, too, and I think the cleanest way to
> solve it would be to introduce optional names for URL patterns.
> Something like this:
>
> url(r'^objects/$', some_view, name='object_view'),
> url(r'^
I'm not sure if there's a ticket for this, but I remember talk about
it being an unnecessary wart which was going to be removed eventually.
Is it in the 1.0 plan?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dja
On Apr 3, 4:48 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote:
> If I recall correstly that was a design decision as you can always nest
> with tags:
I'm not sure if this was an official design decision. As the ticket
writer, I suggested that this was a solution.
The tag could easily be extended
Can we please have some discussion over adding "required" and "error"
HTML classes to fields in newforms as_ methods?
Two tickets of relevance:
http://code.djangoproject.com/ticket/3512
http://code.djangoproject.com/ticket/3515
It'd be good to see a design decision for this (and if 3512 is good,
On Apr 4, 1:08 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> {% url some_variable arg1,arg2,... %}
> would work.
With the confusions of having mixed quoted/unquoted sections in the
one tag, I'm not sure this is worth it.
Like you mentioned, it's quite a specific use-case for requir
I'd like to challenge the closing of
http://code.djangoproject.com/ticket/2229#comment:4
I do see Russell's point about syncdb not having schema-evolution
behaviour for data fields, but it DOES have schema-evolution for
missing tables - you don't have to drop the whole app. So why can't it
creat
tonnzor wrote:
> Yes, the comments are invalid, but in this case it should be ignored
> and printed as-is:
>
> Hello
> {# this
> comment
> has
> newlines #} World! some more text
This is a bug with the template lexer. Any token starting with open
tag text is incorrectly treated as a node of that
On Apr 6, 7:07 am, "Mike Axiak" <[EMAIL PROTECTED]> wrote:
> Well I can't help but post a more complete solution (;-)) located
> athttp://www.djangosnippets.org/snippets/157/.
>
> To be honest, I find Django tries very hard to be compliant with W3C
> (adding things in favor of WCAG, using XHTML
Or even require a superuser?
On Apr 16, 6:00 am, "Baptiste" <[EMAIL PROTECTED]> wrote:
> Oh, and maybe we can check if request.user.is_authenticated() and
> request.user.is_staff() before enabling it ?
>
> On 15 avr, 19:58, "Baptiste" <[EMAIL PROTECTED]> wrote:
>
> > I am +10 on this patch.
> > I
On Apr 18, 3:48 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Unfortunately, the AutoEscapingAlternative page uses strawmen to try and
> make its arguments.
Ok, it's less "controversial" now.
--~--~-~--~~~---~--~~
You received this message because you are su
On Apr 18, 3:48 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> In the past threads, we basically had consensus anyway, I'm not sure
> that revisiting everything again is worth the hassle.
Without trying to rock the boat... reading back, I'm not sure there
was a resounding consensus.
I actua
I'm not sure this is really adding that much. Why can't you just use
reverse as it stands? It doesn't seem hard to do:
>>> some_id = 1
>>> reverse(some_view, kwargs=dict(id=some_id))
'/event/1/'
or:
>>> reverse(some_view, args=[some_id])
'/event/1/'
--~--~-~--~~--
Thinking about it more, I wouldn't actually be against Malcom's
autoescaping solution being on by default - I do see the importance of
solid XSS protection!
I can also see a solution which would maintain backwards compatibility
for old sites:
TEMPLATE_AUTOESCAPE=False in conf.global_settings
TEMP
On Apr 19, 1:36 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Since this is actually a good idea, we should give credit where it's
> due: the whole theory behind this (and most of the details) is Simon
> Willison's creation. I just wrote the code and polished off some of the
> less smooth co
I put together my take on django.contib.thumbnails and posted it as a
patch
http://code.djangoproject.com/ticket/4115
Please read through the documentation and give some feedback.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
On Apr 23, 9:25 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> This is a really great patch. I read the patch but have not attempted
> to use yet. Here are a couple of thoughts:
> - I think the patch file itself may be a little messed up. I see that
> several of the files are repeated. I
Following on from an IRC discussion:
[15:52]SmileyChris: Maybe the ticket DB could use another
level of granularity in triage: "Low hanging fruit"
[15:53]mattmcc: yea, i think it could
[15:53]Since 'design decision needed' could be anything
from a major con
I'm still convinced this is a very common use-case.
I like Amr's take on it:
We don't introduce any context bloating
We don't require templates to use RequestContext
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
http://code.djangoproject.com/ticket/4176
--~--~-~--~~~---~--~~
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 g
Regarding suggestion 1:
You can do that already by providing a formfield_callback function. I
made a helper to create a callback function to exclude or only include
certain fields:
http://www.djangosnippets.org/snippets/209/
--~--~-~--~~~---~--~~
You received this
Indeed. And I do so miss the weekly roundups ;)
On May 16, 10:35 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 5/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> > It's probably more important to check the web page than follow the
> > developers' list, I would say. It's a bug if we
Right, check out the ticket again - new patch up.
http://code.djangoproject.com/ticket/4115
On May 17, 1:19 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> The most common use case is that someone wants to create the tag
> with the appropriate height and width. If the incorrect values are
+1 for {# #} for me too.
--~--~-~--~~~---~--~~
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
This has been discussed earlier on the list, but a simple solution was
sitting there waiting to be implemented so I just put a patch together.
Does anyone see any problems with it?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
Oops sorry, I meant to include the ticket #:
http://code.djangoproject.com/ticket/500
--~--~-~--~~~---~--~~
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
True, Jan. I have updated the patch so it won't break the admin app now.
--~--~-~--~~~---~--~~
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
I don't share gismo's view that we need a unique extension. I'm happy
with html extensions for my html files but it seems silly to require
one extension for all templates! What about other types such as emails
or dynamic css files? We shouldn't be forced to use a single file
extension for all temp
I wrote a working solution today for a challenge, I just wanted throw
around some ideas before submitting a patch - even though it's probably
a pointless gesture this close to a major merge. Here's a summary:
First of all, none of this requires client side encryption but it's
used if Javascript i
Oh what the heck, here's the patch:
http://code.djangoproject.com/ticket/1534.
I'd still like to hear some comments. :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gro
Meh. It's a "wontfix".
--~--~-~--~~~---~--~~
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
+1 to creating urls.py
-1 to changing project-wide URLConf
+1 to comment to copy in urls.py
:)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django
I think it'd be great, Luke.
--~--~-~--~~~---~--~~
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 em
I'm not a fan of the current permissions system. It'd be neat to see
admin permissions evolve to a *nix-like system of user/group/all,
read/write permissions per object.
Objects could be linked into the permissions system with a single
foreign key through to a permissions object containing the r/w
An ACL system seems appropriate as long as all objects of one type have
the same rights, which often isn't the case in the web environment.
For example, someone was asking recently in the Django Users group how
they could allow users to only edit their own posts. This was what
sparked me starting
I agree that maybe an object level ACL system could also be a solution.
The main problem I see with a fine-grained ACL system is that it turns
quickly into Zope permission soup (for those that have played with
Zope).
You quickly get so many permissions per object - it gets confusing fast!
--~--
On Sep 11, 1:12 pm, Tobias McNulty wrote:
> Hi All,
>
> I may be missing something, but queryset.delete() seems oddly implemented in
> Django. It does a select to get all the IDs to be deleted, and then deletes
> them, in blocks of 100 I believe, by ID.
It's because .delete() is emulating the
Just throwing the idea out there, it would be possible to keep the tag
completely backwards compatible by using a slightly different syntax
for variables.
Standard non-variable access stays the same: {% url home %}, {% url
edit-profile profile.pk %}
Variable access is done via a "var=" first argu
On Oct 16, 2:09 am, Andrew Godwin wrote:
> So, from what I can work out, this is a proposal for an {% extends %}
> tag which allows you to extend from the parent template of the same name
Just to chime in, I like this proposal.
IMO: If a designer wants to override a third party's template (by
al
On Oct 16, 8:35 am, Łukasz Rekucki wrote:
> Which "x.html" should be chosen ? the one from admin or the one from
> external app "A" ? Both are valid uses. There is a dangerous
> temptation to say "next that would be loaded after this", but that
> depends on loaders and application order - lets do
In my use of TemplateResponse in a real project, we encountered two
gotchas that I can think of off the top of my head:
1. You need to explicitly bake the response if you are testing using
assertContains
2. You need to explicitly bake the response before the
contrib.messages middleware
On Oct 23,
= RequestFactory().get('/')
> template = Template('foo')
> response = TemplateResponse(request, template)
> self.assertContains(response, 'oo')
>
> Can you please provide more details?
>
> On 23 окт, 00:21, SmileyChris wrote:
>
>
>
On Oct 27, 5:35 am, Łukasz Rekucki wrote:
> I would like to bring this up again, because this is something that
> would really improve readability of my templates. I'm mainly
> interested in ticket #7817 (the include tag changes), but extending
> "with" tag (ticket 9456) would keep things consiste
It's cool that runserver takes away the hassle of needing to add in
your static url (is this documented? I didn't find it in my skim) but
doing it by default seems pretty backwards incompatible, even if we
are just talking about the dev server.
My suggestion is that StaticFilesHandler only does it
On Oct 29, 2:45 pm, SmileyChris wrote:
> doing it by default seems pretty backwards incompatible, even if we
I was a bit terse, let me expand.
STATICFILES_URL defaults to '/static/'. The StaticFilesHandler (which
is now what is used by runserver) swallows requests to this url.
On Oct 31, 8:26 am, Ivan Sagalaev wrote:
> Russel and others: do you think the issue of accidental baking is a
> show-stopper here?
It seems a simple enough proposal that trying to access the content
property would raise an error until it is explicitly baked. Problem
solved.
--
You received t
On Nov 3, 5:58 am, "Tom X. Tobin" wrote:
> Do the Git-using core developers have a preference for merge vs.
> rebase for updating an upstream-tracking branch? I prefer to rebase
> to keep the changes in question at the branch HEAD, especially if the
> branch hasn't been pushed publicly yet, but a
On Nov 3, 1:47 am, Carl Karsten wrote:
> On Oct 28, 9:45 pm, SmileyChris wrote:
>
> > My suggestion is that StaticFilesHandler only does its magic if
> > 'django.contrib.staticfiles' is found in INSTALLED_APPS. Does that
> > sound acceptable?
>
> Is
Hi Will,
I've reopened the ticket, because that's elegant enough for me.
I remember having this discussion in IRC either with you or someone
else a while back and couldn't come up with any negatives to providing
this, as long as obvious caveats of tags/filters potentially relying
on the original
Thanks for following up, Luke.
I understand your point of view, but personally, I'm fine with an "all
bets are off using built-in filters/tags" clause on a custom escape
method.
While you'd expect that addslashes would just work, I'd take the
opposite expectation and assume that any filter / tag u
On Nov 14, 5:52 am, Daniel Moisset wrote:
> In most cases we sent a reply back
> to the submitter asking for more details about their problem, but the
> ticket remains in the "Unreviewed" state, still taking the time of
> other triagers looking for tickets to review.
>
> Many projects have a "need
On Nov 17, 10:10 am, Luke Plant wrote:
> Well, if your ticket hasn't received the attention you think it
> deserves, then it is, but you waited less than 10 minutes from filing
> the ticket!
Agreed, perhaps a bit hasty :)
But in any case, I just committed it.
--
You received this message becaus
I know that a URL resolver refactor is on Malcolm's neverending todo
list. When he starts getting back into it, feel free to remind him of
it. :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gro
On Jun 29, 9:42 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Jun 28, 10:01 pm, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
>
> > If you add the timestamp into both the hash and the token then you can
> > achieve a more granular expiration policy.
>
> That's the approach I use for djangopeopl
Although, as Alex points out, it should be obvious by the name of the
model that it should be passed a QuerySet, I think that the fact that
a list has a "count" method means that a sanity check could be helpful
for debugging.
It's a dead easy change with minimal overheads so go ahead and open a
t
On Sep 19, 9:17 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Sep 18, 6:39 pm, Michael Elsdörfer <[EMAIL PROTECTED]> wrote:
>
> > I remember this coming up on django-users and IRC once or twice, and
> > never thought too much about it, but currently, template inheritance
> > and includes d
On Sep 28, 1:13 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Joseph Kocherhans wrote:
> > On Sun, Jul 6, 2008 at 6:27 AM, Ivan Sagalaev
> > <[EMAIL PROTECTED]> wrote:
> >> ## Proposal
>
> >> To fix this I was thinking along the lines of:
>
> >> class ArticleForm(ModelForm):
> >> cl
Bah, it was just prototype code but point taken ;)
I do feel like it leads to slippery slope though. LikeMichael said,
"why stop at widgets?" I often need to change labels and help text
too.
On Sep 29, 8:56 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> SmileyChris wrote:
&
I think that auth messages are the wrong way to do it most of the time
they are used (including django core code) anyway. They are usually
used to inform that an action worked (or didn't) -- this should be
done as session messages, not user messages.
--~--~-~--~~~---~--
This is exactly why my patch in the session messages ticket [1] makes
the messages lazy.
[1] http://code.djangoproject.com/ticket/4604
On Oct 28, 1:59 pm, bo <[EMAIL PROTECTED]> wrote:
> Actually i've found that the issue lies with the
> TEMPLATE_CONTEXT_PROCESSORS
>
> django.core.context_proces
On Oct 29, 5:50 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> From the looks of it, the patch onhttp://code.djangoproject.com/ticket/4604
> is heading this direction
> re: backwards compatible and part of contrib.sessions.
>
> Maybe SmileyChris can speak to both
; context_processors.auth() function a lazy entity so it only hits any
> session/DB/messages/etc,etc when 'called' from inside a template or
> view.
>
> bo
>
> On Oct 27, 6:58 pm, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> > This is ex
Note, that this is actually a dupe of #3481.
Regarding, {% else %}, see what Malcolm said about it -
http://code.djangoproject.com/ticket/3481#comment:2
On Oct 29, 1:18 pm, oggie rob <[EMAIL PROTECTED]> wrote:
> > {% for item in grocery_list %}
> > {{ item }}
> > {% default %}
> > Nothing to
On Nov 2, 2:52 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> Assuming vary_on_get() with no parameters means no variance (other
> than the HTTP Vary headers), then [...]
That seems confusing - the decorator name seems to imply that it would
vary on any get attribute (even though this is the def
There are currently inconsistencies with how ModelAdmin decides on
what query set (i.e. manager) it's using.
Issue 1: The change list it uses ModelAdmin.queryset() while the
change view uses ModelAdmin.model._default_manager
Issue 2: Also, when searching, ChangeList uses the base QuerySet model
It's time for an annual review of http://code.djangoproject.com/ticket/3512
I know that the as_* methods are spat at, but I still find them useful
- this is one of the things that would make them that bit more usable.
The latest patch (albeit 10 months old) still seems to make sense to
me. Bar th
If any committer wants to look at it, I consider this patch feature-
complete (and has some unit tests now)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send emai
> #3896 - pass value to field specific clean function [2]
How expensive is a try/except?
Call clean_foo passing the value as a parameter and if that fails, use
the old method (setting the value in cleaned_data, then calling
clean_foo with no parameters)
Seems backwards compatible to me.
--~--
I'm more convinced that #4105 is a better way (primarily because it
doesn't introduce the requirement of using RequestContext and add
another variable to the context namespace). But hey, like Marc says -
anything's better than what we have now! :)
On May 26, 3:15 am, "James Bennett" <[EMAIL PROT
I like the proposal.
> The javascript
> portion seems fine, however I would see media as a class, not as a
> method, ala a model's Meta class:
Yea, I tend to agree.
> This gets a little complicated: tags are only allowed inside
> tags, otherwise you have invalid (X)HTML.
I'm not sure how that
101 - 200 of 338 matches
Mail list logo
