Kevin Dangoor, el viernes 11 de noviembre a las 08:34 me escribiste:
> On 11/10/05, Sean Cazzell <[EMAIL PROTECTED]> wrote:
> > Now in your kid template you have paginator.has_next,
> > paginator.has_previous, etc. The paginator.page_range function will let
> > you do lists of available pages like gooooooogle does on large search
> > results :)
>
> These are cool features. I think I like the decorator suggestion,
> because it can automatically manage the incoming request parameters.
> I'm somewhat torn about that, though, because explicitly naming the
> parameters for the page position doesn't require guesswork on the part
> of the user.
>
> I'd be interested in hearing more opinions about decorator (with
> implicit request parameters) as in Leandro's message and independent
> entity as in Sean's message.
The implicit request parameters name can be simplified to the user
providing a function to get those parameters based on the name selected in
the decorator. Something like this could do the job (I didn't think it too
much and I didn't test it either):
def get_pager_params(name):
def var(var):
return 'tg_pager_' + name + '_' + var
_from = whereever_the_post_get_vars_are[var('from')]
size = whereever_the_post_get_vars_are[var('size')]
return (_from, size)
whereever_the_post_get_vars_are is supposed to be the dictionary where
request variables are. I think you get the idea...
Anyways, now that you mention it, maybe is not a great idea to use
implicit names, but I still think is easier for the user to specify just 1
meaningfull name than 2 weird request variable names.
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
.------------------------------------------------------------------------,
\ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 /
'--------------------------------------------------------------------'
Never let a fool kiss you, or let a kiss fool you
