Right, it makes sense to put display logic in the views/templates. And of course, the actual building of the tables will go there.
Does that apply to the actual sorting of the data as well? It seems to me that it's something most efficiently accomplished at the database level. And then... what fields it's sortable on (e.g. you can sort by name, but not by slug) seems to me to be a property of the model. Not in terms of which column headers are linked for sorting in the display (which is very clearly view or template logic), but in terms of what sorting keywords would be allowed/rejected in the view when processing the URL -- should the view refer back to the model for that? Especially since I'm going to require several views for each data type, and it seems a shame to maintain the sortable-fields list separately for each one. Or maybe I'm just making this too complicated for myself? Thanks for your help. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
