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
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 29, 4:48 am, Marc Fargas <[EMAIL PROTECTED]> wrote:
> My count at the end of the thread is:
> #1278: 4 votes
> #4105: 4 votes
>
> So I thow a coin to the
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
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 s
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 yo
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 i
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 I
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
pro
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, t
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
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,
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
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 IRC
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 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 wip
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 %} wor
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 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
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 the
*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 this
Nice to see you back! :)
> I hope to start working on the RLP branch once again, I've merged the
> RLP branch to the latest trunk.
You'll probably find more worth in merging to the new-admin branch now.
--~--~-~--~~~---~--~~
You received this message because you
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 th
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.
-
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
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
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 co
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 be
On Jun 20, 5:03 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> My code is below. It wouldn't take too much to
> convert it to a Django template filter. What does everyone think?
Interesting filter.
Personally, I'm not sure this is useful enough for core.
--~--~-~--~~
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 w
> 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
s
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.
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 t
I suggest we rename this to something like "Django status report" or
"Django activity".
Then if a week (or 10) is missed, no-one can complain ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gr
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.
render_t
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. ;)
S
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 django-develop
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 called
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 labels
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
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 t
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 wo
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 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? ;)
--~--~-~--~~~---~--~~
Yo
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.
H
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 27, 2:51 pm, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> On Jul 27, 12:34 pm, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> > Reading through the mod_wsgi docs [1], I came to a section explaining
> > a problem with Django's core HTTP handling (sear
On Jul 27, 4:16 pm, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> Ahh, I read the way the patch was being applied the wrong way
> around. :-(
>
> Anyway, one potential reason why using req.uri may be bad is that
> Apache does not do complete normalisation on it. Thus, one can get
> repeating slash
On Jul 27, 5:09 pm, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> It sounds like you are saying then that the base.py change results in
> what I refer to as the desirable behaviour for urls.py.
Exactly. That change ensures that the url (forward) resolver doesn't
need to worry about SCRIPT_NAME (i
Sorry bout the unfinished second half of that last message, I was just
thinking through type and I meant to delete it before posting.
On Jul 27, 4:16 pm, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> The other problem is that although with the better WSGI adapters
> SCRIPT_NAME is provided correc
On Jul 27, 7:09 pm, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> BTW, it would be nice if the docs (docs/*.txt) could be viewed
> under the admin interface. The text to html conversion could be
> done during the request.
May I suggest this?
http://smileychris.tactful.co.nz/ramblings/django-docume
On Jul 29, 10:19 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Reverse URL construction (especially w.r.t things like HTTP
> redirects) is the big missing part.
We obviously need some way to get the SCRIPT_NAME from request to the
reverse resolver. Can we rely on SCRIPT_NAME remaining a con
On Jul 30, 2:33 pm, "Mario Gonzalez" <[EMAIL PROTECTED]> wrote:
> Hello! one week ago I opened this
> tickethttp://code.djangoproject.com/ticket/4928please take a look when you
> can. It's got a patch also.
Reviewed.
--~--~-~--~~~---~--~~
You received this mess
Thanks for updating, Gary. I was letting it slide until after newforms-
admin hit. Good to see it's got a committer champion now ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
/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 PROTE
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 bac
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 2, 4:03 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> The one thing Jacob and I
> agreed to change at OSCON was to move to "autoescape on" and "autoescape
> off", rather than "autoescape/noautoescape" as the tags. This way, if
> somebody solves the impossible and comes up with a way t
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
Keeping documentation up should be rather high priority. This ticket
has been sitting for a while untouched. Some love, anyone?
http://code.djangoproject.com/ticket/4853
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Grou
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 it.
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 ar
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 ensure
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 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 %}
{{ my_u
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, 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 th
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 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 the
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
re
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 they
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 eithe
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 safely.
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.
B
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.
>
>http://example.com/admin/myapp/poll/?id__lt=
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 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 ju
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
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
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/)
It has always made me wonder why it isn't even overridable. Is there a
design decision behind this or has it just never been asked?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
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. I
(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
too).
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 SEL
On Sep 10, 10:16 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> > I think my refactoring of django.core.management to let each command
> > register its own options is complete.
>
> Great stuff, Todd. I've committed it in [6075].
It would
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'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 t
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. Feel
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 thi
Reading http://code.djangoproject.com/ticket/3997, I think this covers
the BooleanField side of thinsg
On Aug 1, 2:12 pm, SmileyChris <[EMAIL PROTECTED]> wrote:
> /me pulls out his horse-beating stick...
>
> First off, the patch in the ticket [1] this thread mentions isn't th
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 BaseFieldsMetacla
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 m
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] htt
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 develope
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
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 som
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 w
We have two independent approaches to the problem: #3512 [1] and #3515
[2].
IMO 3512 handles the problem better, but then I'm biased because I
provided a patch for that one :)
Could we have a committer's design decision on the overall issue? How
(if at all yet) is this handled in newforms-admin?
[6506] fixed #5744.
Do we still need django.newforms.forms::SortedDictFromList?
The only thing which the newforms code has extra is its own copy
function which uses deepcopy. I'm at a loss to see why we're using it
there and not on the main SortedDict copy method.
--~--~-~--~~-
On Nov 8, 6:08 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> If/when we ever do finally sit down and implement an auto-escaping
> proposal, I'd like to suggest we also just go ahead and turn on the
> CSRF middleware by default
Why do those two have to be tied together?
How about we just def
On Nov 8, 4:30 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> When you pass in a subclass of Form, it's already got its fields in
> the right place, but more importantly, it triggers that syntax
> checking again, where it looks for new fields. It basically copies
> fields from a parent class, the
201 - 300 of 338 matches
Mail list logo
