Nymbl, I definitly agree that something like that would be ideal and is
important if developers are able to get the full power out of generic
views.
On Nov 14, 8:38 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I have an idea. Instead of a 'message' parameter, there could be a
> on_success
Here's how to run all doctests in a directory:
$ manage.py shell
import re
import os
import string
from doctest import testmod
django_dir=r'/path/to/source/'
trim=len(django_dir)
dots=string.maketrans(r'\/','..')
init=re.compile(r'\.?\.__init__')
skip=('django.bin.make-messages','django.contrib
You can take a look at this patch
http://code.djangoproject.com/ticket/2070
--~--~-~--~~~---~--~~
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@googleg
On 11/16/06, binberati <[EMAIL PROTECTED]> wrote:
> This is what came to my mind a second ago (maybe two) after reading
> James Bennett's blog entry 'Django tips: get the most out of generic
> views'[0].
Some of these ideas sound really cool! I'd suggest focusing on one or
two of them rather than
Sorry for not asking this in the first question...is there a
downloadable tarball for this branch? I can't seem to find it on the
site ... but there is so much info on the site... thought I might just
be missing it.
Thx for any info.
On Nov 17, 3:23 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wr
I have a similar need... we just started looking at django today. I
downloaded the apt-get'able version today I'll have to find the
branch and download it Monday.
Can I backwards engineer from multiple legacy db's with this
branch...or will I need to manually write the code for the model?
Th
Gary Wilson wrote:
> And that is sort of my point. Is it confusing that text|title doesn't
> behave the same as text.title()?
no, I was unclear: the c.l.python poster found it confusing that
text.title() has such a brain-dead notion of that a word is. he
wasn't a Django user, as far as I ca
It's important to remember that when it comes to templates the target audience
consists of people who don't know Python. Trying to explain to them that
Joe'S Diner is "correct" because Python says it's correct is, well, ...
Yes, consistency is good, but this is an exception.
Jacob
--~--~--
On 11/17/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> someone recently complained that str.title() wasn't quite as clever as
> text|title
> over at comp.lang.python, so I assume that whatever you do, someone will
> think it's doing the wrong thing.
And that is sort of my point. Is it confusin
> The current filters work for me as they are, and I can see how changing
> them may cause problems for me (capfirst will not convert an acronym
> like NASA to lower case, whereas capitalize will).
Yes, I think will all of these that it depends on the data you have to
start with. If you have acr
Gary Wilson wrote:
> I did realize an example where the title filter's implementation would
> be desired. When you've got a possessive noun:
>
Template("{{ text|title }}").render(Context({"text": "the boy's blob"}))
> "The Boy's Blob"
>
> as opposed to:
"the boy's blob".title()
> "The
> So, I am proposing:
> 1) Adding a capitalize filter that mimicks str.capitalize.
> 2) Adding comments as to why the title filter doesn't simply return
> the output from str.title.
> 3) Renaming the current title filter and adding a title filter that
> mimicks str.title.
> 4) Removing the cap
The django source code in the boulder-oracle-sprint branch has had the
trunk HEAD merged in, and now passes all but 4 of the 65 tests in the
suite against my 10g and 9i database instances.
If you do Oracle, or if you're an Open Sourcerer who's willing to pinch
his or her nose for a bit, we could
On 11/17/06, Jani <[EMAIL PROTECTED]> wrote:
> Is there any reason not to use same argument names in database fields
> and form fields? I have been playing with newforms and I constantly
> write "max_length" argument in CharField as "maxlength" which is used
> in database and oldforms CharField.
Adrian Holovaty wrote:
> On 11/16/06, gabor <[EMAIL PROTECTED]> wrote:
>> - what is the plan, how should incoming data (GET or POST) handled?
>> some possibilities:
>> [...]
>> - we assume it's DEFAULT_CHARSET. we do not failover (means that if that
>> data is not in DEFAULT_CHARSET, the newforms
15 matches
Mail list logo
