Implemented #16873: specify the name of offset to use in google.tpl, in order to have more than one navigator one a page

[jdespatis]

Implemented #16873: specify the name of offset to use in google.tpl, in order to have more than one navigator one a page

[gggeek]

If you want to change this, please do something else: have the navigator tpl receive the value for the offset directly instead of using the view_parameters, which are not passed to it explicitly. It just makes much more sense, and removes a dependency on view_parameters variable.
For keeping backward compatibility, in paginator tpl:

• if $offset is give, use it
• if not, use $view_parameters

[jdespatis]

I'm not sure to understand.

Even if I give the value of the offset (let's say 3) to the paginator to avoid to the latter to get it from view_parameters, the paginator will still need to print links towards previous pages and next pages.

And for that, it needs to get the current url and add some params in it, /(offset)/5 for example, right?

That's this string 'offset' I'd like to be able to change for each navigator on the page.

That way, one a page with 2 navigators, the first would put /(offset1)/ in the url, and the second navigator would put /(offset2)/ in the url.

For instance:

{include name=navigator
         uri='design:navigator/google_offset_as_param.tpl'
         page_uri=$node.url_alias
         item_count=150
         offset_name=offset1
         view_parameters=$view_parameters
         item_limit=10}

{include name=navigator
         uri='design:navigator/google_offset_as_param.tpl'
         page_uri=$node.url_alias
         item_count=110
         offset_name=offset2
         view_parameters=$view_parameters
         item_limit=10}

In order to be able to support this feature, is there another way than the one used in this patch?

[gggeek]

You are right: you still need to pass the name of the offset parameter to the paginator for it to be able to build the links.

But I still think that having the paginator making usage of the $view_parameters is bad:

• it is hardcoded in the template
• it is not passed as a parameter in the include calls, so it feels a bit like blackmagic

So why not:

• pass the value of current offset as direct parameter in include call (if not passed, use $view_parameters by default)
• pass the name to be used for it in building the url, as you proposed

[gggeek]

ps: while at it, this could be implemented in other navigator templates...

[jdespatis]

I'm not sure the paginator can do without view_parameters indeed.

Imagine a page which has as url: www.domain.com/module/view/param1/param2/(key1)/45/(key2)/joe, which needs to show 1 paginator.

As the latter will need to show links towards previous and next pages, it needs to loop over view_parameters in order to add all elements, except offset where the paginator needs to override with the correct value to go to another page (or inject it if no offset already set in view_parameters), in order to have for example:
www.domain.com/module/view/param1/param2/(key1)/45/(key2)/joe/(offset)/3

If the value of the offset was given to the paginator only, the latter would lost all those param1/param2/(key1)/45/(key2)/joe, and then the behavior would change (imagine a module that is a little search engine using key1 and key2 as key to search)

Further more, yes the paginator relies on view_parameters, but from my memories, all code using the paginator always give view_parameters as param (have a look at my previous code, it's indeed a copy of the inclusion of the google paginator in ezwebin), in order to avoid this blackmagic behavior you're talking about and about I agree with (if view_parameters wasn't given as param, which hardly never occur from what I've seen through ezwebin templates)

+1 for adding this feature to other navigators.

Indeed, the thing that can be tune in this patch is the name of the param given to the paginator.
From now, I've called it offset_name to make the patch clear, but it could be something shorter like 'id', or whatever you want

And after choosing the name of this param, it could then be broadcasted to other paginators I guess