xbmcswift2
xbmcswift2 copied to clipboard
add matching view name and its args back to plugin.request
This is more a draft/idea than a full PR.
Problem is, when you have a view with multiple URLs but want to add pagination you need to know the actual views function name and params.
Example code to show the problem:
@plugin.route('/videos/<page>/')
def show_videos(page):
items = api.get_videos(page)
items.append({
'label': '>> Next Page >>',
'path': plugin.url_for(
'show_videos',
page=(int(page) + 1)
)
})
return items
@plugin.route('/videos/<artist>/<page>/')
def show_videos_by_artist(page, artist):
items = api.get_videos(artist, page)
items.append({
'label': '>> Next Page >>',
'path': plugin.url_for(
'show_videos_by_artist',
page=(int(page) + 1),
artist=artist
)
})
return items
The views can't be merged to one "multi route view" because the next-page-endpoint is unknown (also it is unknown if the endpoint requires one of the optional kwargs). Of course in this simple example the code redundancy would not matter, but there are much more complex examples possible. Think about a view which has multiple content altering parameters like "sort_by, sort_order, artist_id, page, ...".
With the change in this PR the views can be merged because the current view (its function name) and its current param-dict is available (for in place patching):
@plugin.route('/videos/<page>/')
@plugin.route('/videos/<artist>/<page>/', name='show_videos_by_artist')
def show_videos(page, artist=None):
items = api.get_videos(artist, page)
items.append({
'label': '>> Next Page >>',
'path': plugin.url_for(
plugin.request.view
**dict(plugin.request.view_args, page=int(page) + 1)
)
})
return items
I would write code like this:
'''
@plugin.route('/videos/
btw, what's the plugin.request.view? it need type more chars and hidden the real target function name, is it really needed?
The benefit of this PR is that you can finally create reusable pagination (and even view-option-choosing) functions like this: https://github.com/dersphere/JamBMC/blob/master/addon.py#L1066
plugin.request.view
is the endpoint name of the current matching view, e.g. used in pagination function.
plugin.request.view_args
is a the dict of all keyword-arguments for the current matching view, e.g. used to alter the page-arg to the current matching view.