On Oct 6, 5:24 am, "Paul Davis" <[EMAIL PROTECTED]> wrote:
> Ben,
>
> I contemplated something like this, but I assumed that field
> properties would clash. For instance, after the call to mapper(...)
> you would no longer have access to Django ORM fields with the
> Model.field syntax (as they
On Sep 27, 12:52 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 9/27/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Sep 27, 6:18 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> > I'm actually waiting for some cod
On Sep 27, 6:18 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> There were also attempts to do schema-evolution in other way, but no
> other project released more than limited alpha versions. I rechecked
> it today.
I'm guessing this could refer to my code.
I'm actually waiting for some code to
Currently the docs [1] say "Note that this should have a trailing
slash if it has a path component."
Common use is now href="{{ MEDIA_URL }}images/a.png" so it seems to me
like you should *always* put a trailing slash in, whether there is a
path component or not.
Am I missing something?
[1]
On Sep 19, 11:44 pm, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> Now we just need to get someone to put it on the site...
+1. Easy to do, looks good.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
I guess it's part of the move, but we seem to have lost a lot of the
attached files!
For example, the recent patch submission to #231,
http://code.djangoproject.com/attachment/ticket/231/max_length_cleanups_with_docs.diff
--~--~-~--~~~---~--~~
You received this
In regards to http://code.djangoproject.com/ticket/5050, Malcolm said:
> This needs some django-dev discussion.[...]
> I also feel a bit suspicious about the design. Both Form and BaseForm end up
> with the same root metaclass (because DeclarativeFieldsMetaclass inherits
> from
So the sprint is ambling along right now. If you didn't get the memo,
the place to be is irc://irc.freenode.net/django-sprint
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
On Sep 12, 3:42 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> So whilst adding it is consistent, it's not really a common way to use
> translation and shouldn't be necessary for that patch.
True, I was getting confused about __all__
Anyway, the ticket now contains full tests and docs.
I've added a functional patch to the ticket
http://code.djangoproject.com/ticket/3457
if some people want to try it out.
Feel free to write some documentation or tests. ;)
PS: I'm no internationalization expert, but ugettext_lazy wasn't in
__all__ of django.utils.translation.__init__ so I had
On Sep 10, 2:55 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> Hmm, I confirm I get the same error on OS X -- it happens after the
> server is reloaded. How strange...
So if we have several confirmations of breakage, shouldn't it be
rolled back?
I wrote a patch [1] to fix counting distinct ValueQuerySets. My test
checks that it works
>>> len(Article.objects.values('pub_date').distinct())
5
>>> Article.objects.values('pub_date').distinct().count()
5
The problem is, this unearthed a new bug: PostgreSQL chokes on the
control test ("for
(well at least this is a different complaint than normal)
On Sep 1, 9:00 pm, onno <[EMAIL PROTECTED]> wrote:
> In the models we write maxlength
Hi Onno,
Not any more you don't. Check out the latest svn version (but we've
still kept it backwards compatible, so it still works with maxlength
On Aug 30, 11:47 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-08-30 at 19:01 +0800, Russell Keith-Magee wrote:
> > On 8/30/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> > > It has always made me wonder why it isn't even overridable. Is the
And the demo was broken (thanks to permissions)... should be working
again now...
On Aug 27, 10:20 am, SmileyChris <[EMAIL PROTECTED]> wrote:
> I've had very positive reports from users of my Django Docs app
> (http://smileychris.tactful.co.nz/ramblings/django-documentation/).
>
I did some work on a new patch for http://code.djangoproject.com/ticket/3583
in the weekend.
What it does is refactor the existing apache auth method (which uses
basic HTTP auth) and add a new method which uses the contrib.auth
authentication.
The patch is ready for checkin (in my opinion) but
I've had very positive reports from users of my Django Docs app
(http://smileychris.tactful.co.nz/ramblings/django-documentation/).
Do the core developers think this something that would be worth
including as part of the core admin app?
--~--~-~--~~~---~--~~
You
On Aug 26, 4:19 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> How about if we just go back to "maxlength" for even the SVN tutorial,
> and hold off changing the tutorial until the latest available release
> of Django includes support for it?
Reverting trunk documentation due to stupidity is
On Aug 25, 2:57 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> > Kinda related, I've always wished for a way to set a default for an
> > admin list_filter. So there's something cool for you to do :)
>
> You want to elaborate on a default for list_filter?
Sure. When you visit the admin list
On Aug 24, 5:18 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 8/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > If not, is it a good idea for me to
> > start on functionality like this with the outstanding tickets
> > currently.
>
>
On Aug 22, 4:12 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> ...then importing a model from application.models.modelA or whatever
> doesn't work out of the box. So, you have to manually set the
> Meta.app_label attribute on each model so that it knows how to work out
> which app it belongs to.
On Aug 16, 5:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> The current latest patch fails in a dangerous way, which is why I'm
> against it. Fail safely (so that my data always gets saved when I call
> save()) and it's up for consideration.
My changes latest patch ensures it fails
On Aug 15, 3:34 pm, sime <[EMAIL PROTECTED]> wrote:
> >clean_field1 = generic_clean
> >clean_field2 = generic_clean
>
> The problem here is generic_clean doesn't know which field it is, and
> I can't pass arguments that way? Don't think we have field.name or
> similar
On Aug 16, 5:51 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> This would be the extent of my refactoring for now. Any strong
> thoughts either way before I go ahead and implement it?
Sounds great! One other thing that would be nice is if the sql
generation methods were refactored too so
Recent checkin http://code.djangoproject.com/changeset/5887 broke
running an individual test:
...>runtests.py select_related
Error: Couldn't install apps, because there were errors in one or more
models:
flatpages.flatpage: 'sites' has m2m relation with model Site, which
has not been installed
On Aug 14, 10:24 am, Gary Wilson <[EMAIL PROTECTED]> wrote:
> Oh, I forgot to mention something about possibly introducing a bug day.
+1
Perhaps with an IRC channel for discussion?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
On Aug 10, 7:27 pm, james_027 <[EMAIL PROTECTED]> wrote:
> Hi,
>
> this might sound stupid but is there a good reason for adding
> HiddenField for newforms?
A Widget (not Field) is responsible for the display - and there's a
HiddenInput widget already.
On Aug 10, 2:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-08-09 at 21:37 +, SmileyChris wrote:
> > On Aug 10, 12:16 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> > wrote:
> > > I'm not sure what the syntax would look like at the mom
Collin has put a lot of effort in to this ticket [1] which is still
waiting as a design decision. The latest patch is (apart from lack of
docs) ready for check-in in my opinion. Could we have a decision on
whether this is worthy?
[1] http://code.djangoproject.com/ticket/4102
On Aug 10, 12:16 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I'm not sure what the syntax would look like at the moment, but it's
> something I need to think about: it would help solve one or two i18n
> rough spots, too.
{% alias my_url %}{% url music "rock","112" %}{% endalias %}
{{
On Aug 7, 11:22 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> I've fixed this in [5826]. Thanks for the eagle eyes :-)
May I suggest always providing a reference in trac in the future. Just
from reading the timeline, this looks like a dodgy change.
On Aug 7, 2:28 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> I believe SmileyChris meant that a ticket should be opened about
> updating the documentation.
Correct
> As mentioned in the comments of the ticket you mentioned above, there
> are times when you do want to en
I know this would be backwards incompatible, but why on earth do our
newform clean_[fieldname] methods need to get the value out of the
self.cleaned_data dict. It just seems so un-DRY.
If there is an edge case where you need to look at the dict, you still
could. But the normal case is that you
The main problem people have with BooleanField is that it raises a
ValidationError if its checkbox widget is left unchecked. here is a
problem, but it's not with BooleanField - *it's with the CheckboxInput
(widget)*.
CheckboxInput should only be able to return a value of True or False.
That's
On Aug 3, 11:32 am, "Todd O'Bryan" <[EMAIL PROTECTED]> wrote:
> Can this possibly be right? If I want to include a single variable that
> includes some HTML (such as {{ form.as_table }}), do I have to turn off
> auto-escaping for everything else in the page?
I'm imagining .as_table will probably
I'm no expert in this area, but perhaps we could use a thread-local
middleware to keep request handy?
Sort of like this wiki solution [1] but put the whole request into
_thread_locals.
Would there be any performance downside in doing that? Is it safe to
do that?
This would solve the reverse URL
On Aug 1, 2:02 pm, mamcx <[EMAIL PROTECTED]> wrote:
> Ok,
>
> Thanks for the pointers (and sorry for the english!).
>
> I work always in the last version of django, so I think is not a
> problem.
>
> I take a look at the proposed pymssql library. So I think the best
> option is build a all-new
/me pulls out his horse-beating stick...
First off, the patch in the ticket [1] this thread mentions isn't the
correct solution. Better would be to change the .get_default() method
of BooleanField.
[1] http://code.djangoproject.com/ticket/2855
On Jun 25, 1:06 pm, Malcolm Tredinnick <[EMAIL
Reading through the mod_wsgi docs [1], I came to a section explaining
a problem with Django's core HTTP handling (search for "SCRIPT_NAME").
I have reopened #285 [2] and attached a patch which seemingly fixes
this. Could I please have some people more expert than me check it out
and provide some
On Jul 23, 4:19 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> You would be fine, but I wasn't sure if you tested on Windows.
Yea, my development box runs XP.
PS: I can't patch your diffs because they don't use the format which
TortoiseSVN accepts and the win32 build of patch falls over on it too.
On Jul 23, 3:53 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> SmileyChris wrote:
> I think the patch looks good. Can someone please confirm that the
> latest patch works ok on Windows.
I guess you mean apart from me? ;)
--~--~-~--~~~---~--~---
On Jul 22, 6:21 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> It's a bug and not intended behavior. I've opened a ticket and have
> attached a patch.
>
> http://code.djangoproject.com/ticket/4952
I've put up a new patch which is pretty solid and ready for a
committer's review.
On Jul 14, 9:55 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Adrian Holovaty wrote:
> > I'd like to add a QuerySet.exists() method, which would return True or
> > False if the given QuerySet contains at least one record. This would
> > be more efficient than qs.count() or len(qs) because it
Keeping the tutorial documentation working should be paramount.
http://code.djangoproject.com/ticket/4615 has been waiting for checkin
for a while. Could a committer please review it?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
Well you only really need two then. Information/neutral doesn't need a
label, it's the "default" in my opinion.
On Jul 10, 2:12 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> I do the same thing, only mine are SUCCESS, ERROR, and INFORMATION. It
> seems like it is a good meme and is pretty
On 7/9/07, Max Battcher wrote:
> You could just leave it as a unqualified tag/slug-style string
I'd suggest leaving it as a list. Then template users have more
control:
[{{ message.labels|join:", " }}] {{ message }}
{{ message }}
Perhaps the SessionWrapper can provide some commonly used
After you've read Jacob's suggested link, attach the patch to
http://code.djangoproject.com/ticket/3481
On Jul 7, 5:22 am, Rodolfo <[EMAIL PROTECTED]> wrote:
> I'm new, so I don't know how to submit a patch.
>
> This patch allow a tag "else" in a "for" loop. When the list is empty,
> it is
Subject says it all... just look at the timeline:
http://code.djangoproject.com/timeline
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On Jun 27, 8:46 pm, "Paul Bowsher" <[EMAIL PROTECTED]> wrote:
> No, this is meant to go at the end of a long view function
> def index(request):
> # Lots of code
> render_to_response_with_req(request, 'home/index.html', {'a': 'dict'})
Firstly, you should be `return`ing this request. ;)
On Jun 26, 10:45 am, Paul Bowsher <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Been using
> Rails for a while (not by choice) and it's a joy to get back into
> Django.
Welcome back ;)
> render_to_response is a great shortcut, however in my opinion it's let
> down by not supporting request.
On Jun 23, 1:55 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> > Documentation should be kept up to date even if there is a bug - it's
> > easy to update it again when the main ticket is fixed.
>
> Strongly disagree, unless there's no forseeable way the bug can be
> fixed. All the incentive
I should really reply here rather than in the ticket:
In that ticket I kinda agree with anonymous (who I'm guessing was
jedie). That ticket has a patch two months old, and since it's not
that critical it could sit there for much longer. Well maybe not in
this case, now it has got some attention.
> This has got me thinking though, do we even really need the two
> linebreaks filters that exist now?
Yes. You're underestimating what the linebreaks filter does.
It breaks the text up into a list, splitting on multiple new-lines.
Each of those list items get wrapped in a (after getting their
Regarding the thoughts on creating a "thumbnails" folder, I just want
to make it clear that we could change the default for template
filters, but the contrib.thumbnails code does *not* enforce a specific
file/directory structure for thumbnails (and I'd rather not introduce
this restriction).
So
On Jun 20, 5:27 am, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote:
> On 6/19/07, James Bennett <[EMAIL PROTECTED]> wrote:
> > I'd be +1 on just switching the whole thing (messages for all users,
> > authenticated or not) to using sessions, in which case
> > django.contrib.auth.models.Message should
On Jun 20, 3:58 am, "Joseph Heck" <[EMAIL PROTECTED]> wrote:
> Out of curiousity, what's the reason to try and keep them separate
> instead of just layering it over the session mechanism?
Mainly due to the limitation of context processors that they can't see
or change the current context.
The
On Jun 20, 1:50 am, Michel Thadeu Sabchuk <[EMAIL PROTECTED]> wrote:
> But coming back to discussion again :D, what does happen if I remove
> an image, it does not remove the thumbnail, am I right? Is there any
> plan to work on this?
Not really... Perhaps there should be a cleanup method you can
In this ticket [1] which adds the ability to override the global
session age setting, there is a discussion going on regarding whether
the override value should set a fixed life for the session or just
change the idle timeout.
[1] http://code.djangoproject.com/ticket/2548
Currently, if ever the
It's not difficult for someone to implement this themselves, but it
does seem useful enough (imo) for core.
I have also contributed a patch to that ticket (sorry for the hijack)
with docs and tests, calling the framework "visitor messages" to keep
it separate from auth's "messages" framework.
On Jun 18, 10:23 am, Mike H <[EMAIL PROTECTED]> wrote:
> Perhaps the example in the
> docs needs updating to show required=False in the cc_myself field?
Perhaps you should make a ticket.
/me cracks the ticket manager whip. ;)
--~--~-~--~~~---~--~~
You received
*Ping* Update on "week in review" postings?
--~--~-~--~~~---~--~~
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
Thanks Michel, those bugs all fixed.
Changing this thread's tact, this ticket s still sitting as design
decision required - what's the core's thinking now? Is it the sort of
thing we want in contrib?
I was thinking that perhaps this could alternately go in an `images`
contrib package in case
On Jun 18, 8:44 am, Mike H <[EMAIL PROTECTED]> wrote:
> class ContactForm(forms.Form):
> subject = forms.CharField(max_length=100)
> message = forms.CharField()
> sender = forms.EmailField()
> cc_myself = forms.BooleanField()
Try cc_myself = forms.BooleanField(required=False)
It
http://code.djangoproject.com/ticket/4551 raises the issue that the
docs say that PhoneNumberField is a subclass of CharField when really
it's an IntegerField.
Now that's an easy fix, but looking at the code a bit deeper it seems
that USPhoneNumberField (the default newforms field) is cleaned to
On Jun 12, 8:56 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> I suspect that if I saw a working patch I might lean a
> bit more towards +0, but it's pretty low on my radar.
Ok, I attached a patch. The funny thing is that that use-case sounded
good but it won't work due to how {% for %}
On Jun 9, 9:32 am, Brian Harring <[EMAIL PROTECTED]> wrote:
> Realize it's hit trunk already,
No worries, we can always open another ticket :)
> but noticed an annoying potential
> gotcha- for single var in a for loop, any changes to the context stay
> put- for multiple vars, the context gets
On Jun 8, 12:58 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> We have, in the past, given out branch
> logins to anyone that wanted them. This has, almost without exception,
> lead to stale branches as the developer involved loses interest, etc.
To true - there is an on-going joke on
On Jun 8, 12:57 pm, "Michael Trier" <[EMAIL PROTECTED]> wrote:
> This looks really cool. Thanks SmileyChris.
And Honza for the initial work on this ticket :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed t
On Jun 8, 10:33 am, Noam <[EMAIL PROTECTED]> wrote:
> ... However, I like my method better since (I think) it keeps
> the block algorithm simpler to understand, and "Simple is better than
> complex" - it keeps the current algorithm, and clarifies what should
> be done if multiple blocks with the
Another solution is that multiple blocks with the same name inside a
template are allowed as long as the template doesn't extend that block
name (raise an error in that case).
This way, it doesn't matter about the "meaningful" block, because if
it's just the parent template which has two blocks,
New patch uploaded, taking into account Brian's thoughts (and fixing a
small bug):
http://code.djangoproject.com/ticket/3523#comment:11
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
On Jun 5, 11:48 pm, Brian Harring <[EMAIL PROTECTED]> wrote:
> Comments on the patch/syntax at least; Offhand, test
> 'for-tag-unpack03' points out some uglyness in the api-
>
> {% for key value in items %}
> {{ key }}:{{ value }}/
> {% endfor %}
Regarding the whole comma/space issue,
Ticket http://code.djangoproject.com/ticket/3523 has been sitting
quietly for a couple of months as a design decision and it's a
reasonably common question in the IRC channel so I thought I'd ask a
core developer for a decision.
The ticket itself relies on a change to context.update, which is
It's a bug with PIL reading OLE files with Python 2.4:
http://mail.python.org/pipermail/image-sig/2006-February/003764.html
Probably worth filing a ticket - it'd be easy enough to catch
OverflowError in our validator.
On Jun 5, 5:06 am, [EMAIL PROTECTED] wrote:
> Since the focus is on newforms
Ticket #611 was reopened just now and the point raised seems valid
enough.
http://code.djangoproject.com/ticket/611#comment:8
Quoting rogerdpack from the ticket comment:
"The problem it generated for me was that say I have a User with a
field 'registered' which is, of course, not editable, then
On Jun 3, 1:41 pm, sime <[EMAIL PROTECTED]> wrote:
> Been hacking admin a bit lately and wondering if anyone else thinks
> the following couple of minor improvements would help.
Yea, all good suggestions!
--~--~-~--~~~---~--~~
You received this message because
In http://code.djangoproject.com/ticket/3583 I've added a patch which
refactors the existing mod_python authentication function and adds a
new cookie based one.
If anyone can, a review would be good. Specifically:
1. Does it work correctly for you? (it does for me)
2. Is the change in patch 2 a
On May 29, 12:32 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 5/29/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> > It would be great to hear from some of the previous "voters" in this
> > thread on their view of #4105 (as opposed to #1278
On May 27, 11:34 pm, itsnotvalid <[EMAIL PROTECTED]> wrote:
> I am hearing somthing called ReCAPTCHA (http://www.recaptcha.net,
> powered by Django ;-) ) which is basically an online captcha service
> API. You may want to look into them as well.
I've got a mostly complete newforms implementation
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
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
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
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
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
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
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
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
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 concern to si
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
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
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
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/'
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
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.
> >
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
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
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
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
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
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
101 - 200 of 289 matches
Mail list logo
