On Mar 6, 3:36 am, Leo wrote:
> This is really cool, thanks for sharing it!
>
> One small question though, would it be better to check TEMPLATE_DEBUG
> instead of DEBUG
> -http://docs.djangoproject.com/en/dev/ref/settings/#template-debug
> ?
Yes, TEMPLATE_DEBUG would be better indeed. Thanks.
On Sat, Mar 6, 2010 at 9:40 AM, Gabriel Hurley wrote:
> I've read through the history on this group about triage process and I
> have an idea I'd like to offer gently:
Thanks for the suggestion, Gabriel. We're always interested in
considered feedback and suggestions. Don't let what I'm about to s
On Sat, Mar 6, 2010 at 5:59 PM, Jonathan S wrote:
>
> On Mar 6, 3:36 am, Leo wrote:
>> This is really cool, thanks for sharing it!
>>
>> One small question though, would it be better to check TEMPLATE_DEBUG
>> instead of DEBUG
>> -http://docs.djangoproject.com/en/dev/ref/settings/#template-debug
Sorry Carl, I agree with pretty much everything you said. I was
talking a bit too abstract and I had misunderstood.
I will concentrate on a few use cases:
with a app level settings.py file i didnt really refer to automatic
import, as that can easily be done now.
I had more like a admin.register in
> This looks really interesting. Is this something that could be
> integrated into Django's template page itself? It strikes me that this
> sort of feedback would be a good addition to Django's own debug page,
> rather than requiring end users to pepper debug tools like try-catch
> block in their
Hello,
Truncatewords is in Django, but I've been missing the (for me) more
obvious "truncate"-filter, which truncates to a specified amount of
letters, which is really important to me for formatting purposes.
After some thorough looking on Google, I found out that I didn't need
to write the filte
Hi Wilm,
This is an issue which has been discussed several times before. A quick
search yields:
http://groups.google.com/group/django-developers/browse_thread/thread/924112bf84709225/56e623e758b08465
http://code.djangoproject.com/ticket/3963
http://code.djangoproject.com/ticket/5025
If you have
http://groups.google.com/group/django-developers/browse_thread/thread/924112bf84709225?pli=1
http://code.djangoproject.com/ticket/5025
The proper solution would be a truncate filter, unfortunately, the
ticket is still sitting on "Design decision needed". (Could someone
PLEASE just take a design de
I'm certainly not discouraged and I appreciate the reply. The
crowdsourced/trust-based system is more what I had in mind; my
suggestion was trying to shoehorn that thought into the existing
tracker.
Given that I love organization and would love to help decrease the
entropy in Trac, maybe you can j
Wow, that's a seriously old ticket! Decision needed for sure.
Wim, if you want to open a ticket for the docs but don't feel like (or
don't know how to) write a docs patch I'm happy to do so. I agree that
the current solution isn't clear enough. Just let me know what number
the ticket is.
- Gabri
It seems like the best place for "project settings"(a) would be applicable
is through some ./manage.py command, perhaps "installapps" or something
along those lines. This would probably be the place to do database
modifications between versions.
(b) could be served by a "readonly" flag in the setti
-1
I personally think that DEBUG mode is the only time anything other
than error logging and a 500 page should happen during an exception,
unless done with exception middleware, or in the view. For a template
to include TRY / END, is definately stripping any resembalence to a
MVC architecture from
12 matches
Mail list logo
