In the interests of the thousands of developers on this list and their
valuable time, I have to agree that this thread is very off topic.
I'll focus on the original question, below is a quick justification
for anyone who is interested.
I can't see a reason to build anything into Django core to
Seeing as we have to deal with a stale data issue anyway, I thought I
would throw an idea into the mix.
I think it'd be nice to have something where the data is a little more
open, allowing anyone to create an index of developers. For example,
each developer who wants to be index sticks a json
A quick note on your approach: What if the user isn't supposed to have
access to certain fields in a customised form?
You probably want to take a checksum as Russell suggested earlier and
put that in the hidden field. Of course, dealing with conflicts will
be harder if you can't show the user
> Deprecate slice, move it to "truncate" and add the ellipsis for consistency.
Slice has other uses, please don't deprecate it :-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
> That seems reasonable to me, but I'll add the stipulation that any
> design proposal must include a commitment to do the implementation,
> and must include all of the admin's pages.
Why? Not all designers can do cross browser xhtml/css (html5?) or even
django's template language, let alone the
I'm not sure what reception you'll get for this suggestion (also given
that all attention is currently on Django 1.2), but I think eventually
problems like these may be best addressed by allowing you as the
developer to write your own customised helper functions/methods to
deal with things the way
> Does this proposal add any functionality that fixtures do not already
> provide?
Convenience. It moves the definition of the site away from the
database, and away from fixtures files and into the settings.
Personally, I am yet to need multiple sites for a single database, and
would much prefer
I thought this was familiar too: <http://code.djangoproject.com/ticket/6988>
Is this the ticket you were thinking of? It seems to have been reopened.
Cheers,
Will Hardy
--
You received this message because you are subscribed to the Google Groups
"Django developers"
I hope I understand your problem correctly, but authentication is
handled by your authentication backend, not your model. Your backend
can return anything you like (eg Foo) and that is what you'll get when
you call authenticate(). This object is given a .backend attribute by
django.contrib.auth,
Thank you for your email.
This is not a bug in Django, it is the correct output when you set
DATE_FORMAT = "%m/%d/%Y". Your desired output will come if you set
DATE_FORMAT = 'm/d/Y'.
The documentation [1] may not be too clear on what formatting is
required, but does give an example which hints
Hi all,
While using templates to produce something other than HTML (latex by
the way), I wanted to use my own escape function, instead of the
HTML-oriented default in autoescape.
This is of course not too difficult with filters and turning of
autoescape, but it would be very nice if I could get
Thanks for the explanation and perfect example Luke.
I thought I would try to be helpful and went through the source code
for all the filters and categorised them (see below). There are 12
filters that can't be used (8 are for html only anyway), 24 filters
may fail unpredictably (like your
> Reading over the discussion, I'm in the same camp as Luke. I can see
> the use case, but I see a bunch of sharp edges that will end up biting
> the user in unexpected ways.
Thanks for dropping by :-) I think I've managed to remove the sharp edges.
The main problem in this thread is that the
Hi Luke,
> First, you depend only on the name of the function - so one that shadows
> a builtin filter won't be treated correctly (as you noted on the
> ticket).
This is true, I really hated this bit. The only thing that might work
is "libraryname.filtername" if it's possible to identify exactly
Maybe we could add a keyword argument to Django's TestCase.assert*() methods
that raises an AssertionError instead of failing the test when the method's
condition is not met (I assume that the test should error instead of
failing).
eg:
self.assertEqual(1, 1, test_assumption=True)
Cheers,
Will
It's true that there isn't any rich API for the Error/Fail distinction. The
best I can think of would be to create a custom exception eg
FailedAssumption, which is raised when the TestCase.failedException (same as
AssertionError) is caught while testing an assumption.
Here are four ways I can
In case there's any confusion in the question, it appears as if adding
a period or braces to a word makes it impossible to be found, even
when the exact string exists in the documentation:
* http://docs.djangoproject.com/search/?q=get=4
* http://docs.djangoproject.com/search/?q=get()=4
*
hey always
type.
Some time in the future, when the older users have died out, you can
unify the three commands, removing or renaming ./manage.py in the
project directory.
I think the new command makes a lot of sense to new users, and it's
much easier for them to remember.
Cheers,
Will
--
Will
ing unnecessary tags is a distraction
Cheers,
--
Will Hardy
m: +49 177 392 89 26
e: [EMAIL PROTECTED]
w: http://www.willhardy.com.au
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gro
isn't a good idea for whatever reason.
Having said that I like the flexible approach of just having a string;
unless you need to store other attributes, there are no great
benefits. Bad data could be seen as more of a usability problem than a
technical one.
Cheers,
--
Will Hardy
w: http://www.will
a newforms-admin module that could be saved to e.g.
"admin.py". This could of course help people port their apps more
quickly and painlessly.
Would this be useful enough to include in django itself?
Cheers,
Will
--
Will Hardy
w: http://www.willha
thinks.
Cheers,
--
Will Hardy
w: http://www.willhardy.com.au
--~--~-~--~~~---~--~~
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@google
22 matches
Mail list logo
