On Wed, 2008-01-09 at 12:02 -0500, Prof. William Battersea wrote:
> Hello,
> 
> On nearly every page of the website I'm creating, I have a list of
> recent articles in the sidebar that works as a complete archive. You
> can sort them by newest/oldest, and page through the entire archive.
> The template code for the pagination looks like this 
> 
> {% for page_number in page_list %}
> 
>     {% ifnotequal page_number current_page %}
>        
>         <a class="deselected"
> href="?p={{ page_number }}&sort={{sort_order}}">{{page_number}}</a>
> 
>     {% else %}
> 
>          {{ page_number }}
> 
>      {% endifnotequal %}
> 
> {% endfor %}
> 
> As a result, as soon as you sort, or page through, the url gets a
> querystring appended to it. I'd like to keep them as clean as
> possible, so I was thinking of only adding the sort_order to the
> pagination hrefs if it's not the default. Something like: 
> 
> {% for page_number in page_list %}
> 
>     {% ifnotequal page_number current_page %}
> 
>          <a class="deselected" href="?p={{ page_number }}
> 
>          {% ifnotequal sort_order default_sort }}
>              &sort={{sort_order}}
>          {% endifnotequal %} 
> 
>          ">{{page_number}}</a>
> 
>     {% else %}
> 
>          {{ page_number }}
> 
>      {% endifnotequal %}
> 
> {% endfor %}
> 
> But I'm unhappy that there's so much logic in the template, and it's
> getting hard to read. I understand that maybe every page shouldn't
> have this list with ordering and pagination, but it's something I'm
> experimenting with, and I'd like to get it working in the best order I
> can. 
> 
> I thought about doing most of the processing in the view and
> outputting the pagination as a single string, but then I've moved at
> least a small bit of HTML into my view. I feel like there should be a
> cleaner way. Am I doing something wrong, or is this an acceptable
> level of logic in the template? 

This looks like a fairly good use for a template tag. Any template tag's
render() method is passed the current template's context as an argument,
so you have full access to the variables you need. And since the tag is
solely dedicated to producing some output string for the template, it
doesn't get too muddled up when you're putting HTML in there, as it's
very self-contained (the intuitive problem with HTML in views is that
you're mixing responsibilities and things get mixed up too much).

I think your feeling it correct: at some point the template logic for a
block like this starts to overwhelm the template layout and asks to be
factored out and template tags are one way to do this. You can either
return a string from the tag (which is directly inserted into the
template at the point the tag is called) or have it return nothing ('')
and put the result into a variable in the context for later use.

Regards,
Malcolm


-- 
Remember that you are unique. Just like everyone else. 
http://www.pointy-stick.com/blog/


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to