Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

2010-03-06 Thread Jonathan S

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. I'll change that.

Now, I'm also planning to show the locals() for each frame. (Similar
to the original django traceback)

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Would a "Feedback" triage stage be helpful?

2010-03-06 Thread Russell Keith-Magee
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 say
discourage you :-)

> When I'm looking for tickets to work on, I often wish there was a
> triage stage between "accepted" and "ready for checkin". On other
> trackers the "feedback" triage stage is for this purpose. It lets
> people who have worked on a ticket indicate it's ready for others to
> look at and approve, and tickets can be bounced back out of the
> feedback stage if problems are found.
>
> Filtering by "has_patch", "needs_better_patch", "needs_documentation"
> and "owner" gets you partway  there, but the flags and ownership are
> not always set consistently... Owner, particularly, is frequently
> forgotten about.

The issue here is that introducing another flag doesn't help in this case.

'needs-better-patch' already covers a lot of the ground of a
'feedback' state. However, rather than assuming that a patch will be
bad, it assumes the patch will be good, and provides a way for
triagers or the core team to pass back feedback that a patch isn't
ready.

Also, as you've noted, the existing flags and states are already
inconsistently applied -- adding another state or flag just adds more
complication, and more ways that a ticket can be incorrectly
configured.

This is all part of the devil's bargain we've made with Trac. We've
left our Trac instance open. The upside is that anyone can help, and a
new user doesn't need permission to start pitching in. The downside is
that anyone can help, and someone "helping" isn't forced to learn the
rules first.

The net result is that Trac is a great way of putting a name to
specific problems. It's a passable way of organizing the todo list for
a release. It has sufficient fidelity to draw tickets to the attention
of the core (the ready for checkin flag). There's a lot of noise, but
the only effective way to eliminate that noise is to apply human grey
matter to the problem. I'm not convinced adding or changing the Trac
states that are available will improve matters significantly.

If we were to make any big changes in this area, I suspect it would be
to move away from Trac altogether. Looking right outside the box,
there might be space for a tool that provides better integration with
the crowdsourced approach to ticket handling that we are using.

To elaborate a little -- Trac provides access to all, but treats all
contributors as equals. We allow anyone to triage, but the opinion of
the triage team matters more than the general community, and the
opinion of the core team matters more than the triage team, and the
opinion of the BDFLs trump everything. A random community member
should be able to provide feedback saying that they think a patch is
ready, and if they make a habit of marking patches that are
subsequently accepted, the 'value' of their feedback should improve.
That said - if a large group of low-trust individuals say a patch is
ready, that patch should also surface for closer attention.

I'm just thinking aloud here -- I'm not aware of any tool that does
this sort of thing, and I'm not committing Django to adopting such a
tool if one does exist (or if one was built). However, if someone is
looking for a pet project, this sounds like fertile ground for
experimentation to me. You could even build it in Django :-)

> I could see it helping the core devs, too, since they'd have to spend
> less time sifting through "accepted" tickets looking for things that
> might be ok to escalate to "ready for checkin".

I don't think this bit is as big a problem as you might think. I can't
say I've ever found myself wanting for tickets to close. The mailing
list, IRC, private email conversations and personal experience provide
a fertile ground for identifying problems than need addressing; on the
rare occasion that I find myself looking for something to do, the
milestone flags and the ready-for-checkin list provide plenty of
material to work with.

Yours,
Russ Magee %-)

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

2010-03-06 Thread Russell Keith-Magee
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
>> ?
>
>
> Yes, TEMPLATE_DEBUG would be better indeed. Thanks. I'll change that.
>
> Now, I'm also planning to show the locals() for each frame. (Similar
> to the original django traceback)

Hi Jonathan,

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 template code.

Yours
Russ Magee %-)

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: dbsettings, and user configurable app settings

2010-03-06 Thread stuff4ash
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 mind, like the appsettings app by
jared.
it would be nice if apps had an easy and constitent way of
"registering" somehow:

a) project settings (settings that affect the installation, etc...
this can include automatic install of dependencies, etc... but
normally do not change, this could be done in a similar script )
b) app settings (settings that change once and while, but that are
meant to be changed by a superuser, or admin)
c) user settings (settings that are to be set and changed by a user
himself, that could be changed in a "profile app")


more to come, now is food time

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

2010-03-06 Thread Jonathan S

> 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 template code.

Hi Russ,

You mean, whether this could replace the traceback from Django without
requiring you to have a {% try %} block in the template?
I'm not 100% sure, but it should be possible to design middleware
which will catch any exception if TEMPLATE_DEBUG and DEBUG are True,
and return this traceback instead.

Certainly something I will take a look at next week.

Jonathan

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



truncate filter

2010-03-06 Thread Wim Feijen
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 filter myself, slice can do the same trick. I didn't get
that from the official Django filter documentation, so my first
question is:
1. Can we update the filter docs, so
a) slice shows an extra example of slicing a string; and
b) truncate_words refers to slice for truncating by letters, to give
readers a helpful hint.
These might sound trivial, but I am pretty sure that I am not the only
one misunderstanding.

2. As I understand it, there are several cases where slice fails,
because of unicode characters? What would be the proper solution to
that, and can we include that in django trunk as well?

Thanks for making Django better and better and better!

Wim

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: truncate filter

2010-03-06 Thread Chuck Harmston
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 suggestions for the docs, they are treated exactly like code:
they're in the repository [1] and are open for patches like any of the code.
Given the frequent requests for a truncate filter, I think that the
requested doc changes would be welcome. Feel free to submit a ticket with a
patch for this.

To your second point, what do you mean by "fails, because of unicode
characters"? Do you mean encoded HTML entities (e.g. &)?

[1] http://code.djangoproject.com/browser/django/trunk/docs

Best,
Chuck

On Sat, Mar 6, 2010 at 7:05 AM, Wim Feijen  wrote:

> 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 filter myself, slice can do the same trick. I didn't get
> that from the official Django filter documentation, so my first
> question is:
> 1. Can we update the filter docs, so
> a) slice shows an extra example of slicing a string; and
> b) truncate_words refers to slice for truncating by letters, to give
> readers a helpful hint.
> These might sound trivial, but I am pretty sure that I am not the only
> one misunderstanding.
>
> 2. As I understand it, there are several cases where slice fails,
> because of unicode characters? What would be the proper solution to
> that, and can we include that in django trunk as well?
>
> Thanks for making Django better and better and better!
>
> Wim
>
> --
> 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...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: truncate filter

2010-03-06 Thread Jerome Leclanche
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 decision already)

J. Leclanche / Adys



On Sat, Mar 6, 2010 at 4:05 PM, Wim Feijen  wrote:
> 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 filter myself, slice can do the same trick. I didn't get
> that from the official Django filter documentation, so my first
> question is:
> 1. Can we update the filter docs, so
> a) slice shows an extra example of slicing a string; and
> b) truncate_words refers to slice for truncating by letters, to give
> readers a helpful hint.
> These might sound trivial, but I am pretty sure that I am not the only
> one misunderstanding.
>
> 2. As I understand it, there are several cases where slice fails,
> because of unicode characters? What would be the proper solution to
> that, and can we include that in django trunk as well?
>
> Thanks for making Django better and better and better!
>
> Wim
>
> --
> 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...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Would a "Feedback" triage stage be helpful?

2010-03-06 Thread Gabriel Hurley
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 just provide a little personal insight
on which of the following you find more helpful:

 1. Community members aggressively marking "needs better patch" so
that anything that has a patch and doesn't have "needs better patch"
is more likely to *actually* be good.

 2. Community members leaving comments on tickets with good patches to
say that they seem ready.

Also, how important is the "owner" status of tickets? It seems silly
to take ownership of a ticket that someone else has done all the work
for... but if that means a completed fix is more likely to get noticed
and checked in then maybe that's the right thing to do?

Your thoughts on the matter really are interesting to me. The
"contributing to Django" docs tell the "how it's supposed to work" but
it's helpful to hear the "how it actually works" first-hand.

Thanks!

 - Gabriel

On Mar 6, 3:56 am, Russell Keith-Magee  wrote:
> 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 say
> discourage you :-)
>
> > When I'm looking for tickets to work on, I often wish there was a
> > triage stage between "accepted" and "ready for checkin". On other
> > trackers the "feedback" triage stage is for this purpose. It lets
> > people who have worked on a ticket indicate it's ready for others to
> > look at and approve, and tickets can be bounced back out of the
> > feedback stage if problems are found.
>
> > Filtering by "has_patch", "needs_better_patch", "needs_documentation"
> > and "owner" gets you partway  there, but the flags and ownership are
> > not always set consistently... Owner, particularly, is frequently
> > forgotten about.
>
> The issue here is that introducing another flag doesn't help in this case.
>
> 'needs-better-patch' already covers a lot of the ground of a
> 'feedback' state. However, rather than assuming that a patch will be
> bad, it assumes the patch will be good, and provides a way for
> triagers or the core team to pass back feedback that a patch isn't
> ready.
>
> Also, as you've noted, the existing flags and states are already
> inconsistently applied -- adding another state or flag just adds more
> complication, and more ways that a ticket can be incorrectly
> configured.
>
> This is all part of the devil's bargain we've made with Trac. We've
> left our Trac instance open. The upside is that anyone can help, and a
> new user doesn't need permission to start pitching in. The downside is
> that anyone can help, and someone "helping" isn't forced to learn the
> rules first.
>
> The net result is that Trac is a great way of putting a name to
> specific problems. It's a passable way of organizing the todo list for
> a release. It has sufficient fidelity to draw tickets to the attention
> of the core (the ready for checkin flag). There's a lot of noise, but
> the only effective way to eliminate that noise is to apply human grey
> matter to the problem. I'm not convinced adding or changing the Trac
> states that are available will improve matters significantly.
>
> If we were to make any big changes in this area, I suspect it would be
> to move away from Trac altogether. Looking right outside the box,
> there might be space for a tool that provides better integration with
> the crowdsourced approach to ticket handling that we are using.
>
> To elaborate a little -- Trac provides access to all, but treats all
> contributors as equals. We allow anyone to triage, but the opinion of
> the triage team matters more than the general community, and the
> opinion of the core team matters more than the triage team, and the
> opinion of the BDFLs trump everything. A random community member
> should be able to provide feedback saying that they think a patch is
> ready, and if they make a habit of marking patches that are
> subsequently accepted, the 'value' of their feedback should improve.
> That said - if a large group of low-trust individuals say a patch is
> ready, that patch should also surface for closer attention.
>
> I'm just thinking aloud here -- I'm not aware of any tool that does
> this sort of thing, and I'm not committing Django to adopting such a
> tool if one does exist (or if one was built). However, if someone is
> looking for a pet project, this sounds like fertile ground for
> experimentation to me. You could even build it in Django :-)
>
> > I could see it helping the core devs, too, since they'd have to spend
> > less time sifting through "accepted" tickets looking for things that
> > migh

Re: truncate filter

2010-03-06 Thread Gabriel Hurley
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.

 - Gabriel

On Mar 6, 6:18 am, Jerome Leclanche  wrote:
> http://groups.google.com/group/django-developers/browse_thread/thread...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 decision already)
>
> J. Leclanche / Adys
>
>
>
> On Sat, Mar 6, 2010 at 4:05 PM, Wim Feijen  wrote:
> > 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 filter myself, slice can do the same trick. I didn't get
> > that from the official Django filter documentation, so my first
> > question is:
> > 1. Can we update the filter docs, so
> > a) slice shows an extra example of slicing a string; and
> > b) truncate_words refers to slice for truncating by letters, to give
> > readers a helpful hint.
> > These might sound trivial, but I am pretty sure that I am not the only
> > one misunderstanding.
>
> > 2. As I understand it, there are several cases where slice fails,
> > because of unicode characters? What would be the proper solution to
> > that, and can we include that in django trunk as well?
>
> > Thanks for making Django better and better and better!
>
> > Wim
>
> > --
> > 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...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: dbsettings, and user configurable app settings

2010-03-06 Thread Jared Forsyth
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 settings (if you were using
appsettings)
and (c) is provided by appsettings out of the box.
So it looks like the thing that needs work/thought/design decisions would be
(a). Could you give an example use case of that sort of "project
installation setting"?

Jared

On Sat, Mar 6, 2010 at 5:56 AM, stuff4ash  wrote:

> 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 mind, like the appsettings app by
> jared.
> it would be nice if apps had an easy and constitent way of
> "registering" somehow:
>
> a) project settings (settings that affect the installation, etc...
> this can include automatic install of dependencies, etc... but
> normally do not change, this could be done in a similar script )
> b) app settings (settings that change once and while, but that are
> meant to be changed by a superuser, or admin)
> c) user settings (settings that are to be set and changed by a user
> himself, that could be changed in a "profile app")
>
>
> more to come, now is food time
>
> --
> 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...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

2010-03-06 Thread orokusaki
-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 Django. If it's a custom per-page error message
that you want, use try: except: in the view, and render the template
with a Django message passed in.

There shouldn't be an "Oops an error happened so we're doing XYZ
because the template said so.", but rather there should be a generic
"Oops, an error happened! Please try again".

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.