Page parameter name

[steveWinter]

This PR resolves #815 in the manner suggested by @garak in that issue - passing the entire SlidingPagination object to the templates to allow the pageParameterName to be accessed.

In the future it would likely be possible to remove some of the local variables which are created as the template is being rendered since they could be accessed directly from the SlidingPagination, however I wanted to keep this PR to solving just the issue at hand.

[garak]

Do we really need to pass the entire Pagination object? I think passing only the options array can be enough.

[steveWinter]

Hi @garak in this comment on the issue you said

Probably we should pass the entire set of options to the PaginationRuntime constructor, while currently we pass only a few.

Did I miss-understand what you had meant? Or not implement it in the way you expected?

Essentially I took the code you proposed, updated it slightly for changed variable names, then modified the templates to pass in that third parameter.

[garak]

Well, I wrote that code a few months ago. Probably I would ask the same question to the past myself: why passing the entire object, when we can pass only the options? Moreover, considering that the object is only used to retrieve the options themselves.

[steveWinter]

I believe your rationale was

I'm sure it works, but it would force use to extract the pageParameterName to be passed everywhere. Moreover, it's not future-proof: if one day we find in the need of another option, we would be forced to add a new argument.

How would you like me to proceed? I can modify it such that we pass only that parameter (which for reference is how is used to work in v5), or we can continue with this approach?

[garak]

Change the method to accept an array, pass $pagination->getOptions(), access the page parameter name from the options array.

[steveWinter]

@garak thank you for your feedback - I've pushed another commit which I hope as implemented things as you intended.