> I can't really imagine that this situation is all that common. I'm not > saying it's never used, but the barrier is a bit higher than just "more > than one person uses this".
Maybe it's just me, but in all 3 projects I have faced with django so far I have had to work around this, the most usual use case for me was having some list that can be navigated with javascript with previous and next buttons that would hide and show the proper elements. And even though I could work it around using "add" on the counter some times it made much more sense to use the object's id or other properties to identify the html element. > It's a fairly simple filter to get the next or previous value given the > forloop.counter variable, so I think if anybody needed this, they could > just knock up the filter (or copy the version you paste at > djangosnippets). That's true, but it gets fairly complicated if you want the same behavior for an outer loop, which would be elegantly solved by forloop.parent_loop.previous_element or similar. Regarding the comments about having to unroll the iterator, that could easily be avoided by maintaining a reference to the previous element in the Node. Anyway, if you don't think it is a common situation I didn't feel so strongly about it anyway, it just seemed like a logical unobtrusive addition to the forloop's context. Cheers, Santiago --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
