Re: Add querystring helper methods to Page class
Hi, I need similar functionality so I develop custom tag "qs" wich is not tight to paginator (I don't know if it is better or not) Used that way: params ... dictionary with query string parameters which was prepared in view p ... any amount of other query string parameters as key=value you want to set directly in template For filtering query string parameters in views for using them as parameters in ORM, redirects etc I use function "dict_pass()" with this pattern: search_params = ('a_day', 'a_month', 'd_day', 'd_month', 'guest_count', 'bedrooms', 'p', 'o', 'ot', 'short') #allowed params params = dict_pass(request.GET, search_params, updated_params) It returns dictionary of parameters of "request.GET" updated from "updated_params" and filtered to have only allowed params here as "search_params". I think Django as a web framework could have an object oriented representation of URI in core to simplify the work with url. It should be easy to set, update and get the whole url as a string and also url parts (host, port, path, etc.) and query string parameters in some clever way without bunch of conditions in application code needed. And also maybe help with proper escaping of urls with not ascii chars to render them in templates. Some inspiration from other web frameworks: http://api.nettephp.com/0.9/Nette-Web/Uri.html http://corelib.rubyonrails.org/classes/URI/Generic.html http://framework.zend.com/manual/en/zend.uri.html I think also get_absolute_url proposal and future url routing enhancements could benefit from it. Cheers, Vaclav -- 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: Add querystring helper methods to Page class
2009/12/22 Ben Spaulding: > I have created a patch that would allow for something much simpler, like so: > > Next page This is what I do in my own homemade paginators. It works well. > Though there has been much talk of creating template tags which would > produce all-out pagination bars, I believe this particular > functionality should be an actual method on the page object for two > reasons: > > 1. This is basic functionality whose end result is hard to dispute > (as opposed to a full pagination bar where markup and features could > be disputed eternally), Actual full pagination-bars could be shipped around as templates, whether to be used in inclusion-tags or included directly. No need to lock ourselves to the one, true pagination-style. HM -- 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.
Add querystring helper methods to Page class
A ticket has already been created for this, but SmileyChris recommended I bring the issue up here. Working with pagination and query strings within a template can be painful. Personally, I have never had a situation when I was paginating using a GET parameter where there were not other parameters that needed to be preserved through out the various pages. Take search, for example. There may be parameters for searching within one or more models, for a particular author and sorting by date. Maintaining all of these parameters within the pagination links takes some serious template logic. {# Linebreaks added for readability. In real life this would need to be one, long line. #} Next page That kind of logic shouldn’t be in a template. I have created a patch that would allow for something much simpler, like so: Next page Though there has been much talk of creating template tags which would produce all-out pagination bars, I believe this particular functionality should be an actual method on the page object for two reasons: 1. This is basic functionality whose end result is hard to dispute (as opposed to a full pagination bar where markup and features could be disputed eternally), 2. This does not require the request context processor to be installed. Note that this patch includes documentation. Tests are still needed. I am not married to the exact implementation, but I and others I have discussed this and feel that this simplicity and functionality belong in Django’s pagination. Ticket: http://code.djangoproject.com/ticket/10941 Patch: http://code.djangoproject.com/attachment/ticket/10941/querystring-methods.diff -- 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.