script.module.simpleplugin - библиотека для создания плагинов

[Roman_V_M]

Кто-то из участников данного форума как-то написал, что Kodi API настолько ужасен, что все пишут для него свои обертки. Я - не исключение. Библиотеку SimplePlugin я написал, в основном, для себя на замену заброшенному xbmcswift2, но не поленился документировать на тот случай, если она еще кого-то заинтересует.

SimplePlugin напоминает xbmcswift2, но использует несколько другой, более простой в реализации метод маршрутизации вызовов плагинов.

Саму библиотеку и документацию к ней можно найти на Гитхабе: https://github.com/romanvm/script.module.simpleplugin

Пример использования (фактически референсную реализацию) можно посмотреть в заброшенном в связи со смертью ресурса плагине ex.ua.alternative.

На форуме нашлись люди, которые используют данную библиотеку, поэтому открываю данную тему, чтобы было где обсудить специфику.

[vl.maksime]

Продолжим беседу здесь....
Можно модифицировать функцию get_url(), чтоб список параметров можно было передавать через словарь?
Сейчас у меня есть ряд параметров, которые не обязательные. Я в параметрах задаю им имя, начинающееся с символа "_". Т.к. заведомо я не знаю, какие из параметров ко мне пришли, а все варианты перечислять не охота, то при формировании ссылки с помощью get_url() я их добавляю в конец строки вручную. Получается что-то типа этого:

url = plugin.get_url(action='list_videos')
url = url + '&' + urlencode(ext_params)

А при перелистывании страниц раздела, по факту все параметры повторяются, меняется только номер страницы. Втаком случае можно было бы упростить код следующим образом:

params['_page'] = params.get('_page', 1) + 1
url = plugin.get_url(ext_params=params)

[Roman_V_M]

Сообщение от vl.maksime

Продолжим беседу здесь....
Можно модифицировать функцию get_url(), чтоб список параметров можно было передавать через словарь?

Передача необязательных именованных параметров функции через словарь - стандартная фича Питона:

def bar(a, ham=''):
    print(a)
    print(ham)

foo = {'ham': 'spam'}
bar('b', **foo)

[vl.maksime]

Сообщение от Roman_V_M

Передача необязательных именованных параметров функции через словарь - стандартная фича Питона

Тогда подскажите, как мне правильно вызвать функцию get_url, чтоб он добавил в адрес переданные параметры + данные из словаря.
Все тот же пример:

def list_videos( params ):
        params['_page'] = int(params.get('_page', 1)) + 1
        url = plugin.get_url(action='list_videos')
        del params['action']
        url = url + '&' + urlencode(params)

Как мне передать словарь params, чтоб url был равен:

plugin://plugin.video.video.az/?action=list_videos&_page=2&_category=0&<остальные параметры из params>

Если я правильно понял, то должно получиться что-то типа этого:

def list_videos( params ):
        params['_page'] = int(params.get('_page', 1)) + 1
        url = plugin.get_url(**params)

А если мне понадобиться комбинированный способ, часть значений из словаря, а часть вручную? То только через словари?

[Roman_V_M]

Сообщение от vl.maksime

Тогда подскажите, как мне правильно вызвать функцию get_url, чтоб он добавил в адрес переданные параметры + данные из словаря.

А если мне понадобиться комбинированный способ, часть значений из словаря, а часть вручную? То только через словари?

См. мой пример выше. Там через словарь переедается именно часть параметров. Словарь с ** добавляется к параметрам, которые переданы явно. Единственный нюанс: словарь в Питоне несортированный, поэтому порядок параметров в УРЛ-кодированной строке будет произвольный. Но это ни на что не влияет.

Повторюсь, это стандартный синтаксис Питона. Рекомендую почитать что-нибудь о передаче произвольного набора параметров в функцию через *args и **kwargs.

И вообще, "под капотом" в Питоне все неименованные параметры передаются в функцию через тупл, а все именованные - через словарь.

[Roman_V_M]

Кстати, хотел посоветоваться насчет механизма маршрутизации вызовов плагина. В свое время для ex.ua.alternative я использовал библиотеку xbmcswift2, в которой использовалась маршрутизация с красивыми путями, позаимствованная у веб-фреймворка Flask. Потом xbmcswift2 забросили, и я стал пилить свою реализацию с блэкджеком и прочими.

Нынешний механизм маршрутизации через action и параметры вызова плагина я выбрал чисто потому, что он проще в реализации и теоретически быстрее. Однако периодически возникает желание добавить такую-же маршрутизацию, как в xbmcsfitw2/Flask. Поэтому хотел спросить: есть ли смысл заморачиваться? Или и так хорошо?

[nightik]

Сообщение от Roman_V_M

Поэтому хотел спросить: есть ли смысл заморачиваться? Или и так хорошо?

есть. это хорошо. согласитесь урл вида plugin://script.plugin/play/1/2/ прозаичнее чем тоже самое но в таком виде plugin://script.plugin/?action=play&show=1&episode=2

[Roman_V_M]

Сообщение от nightik

есть. это хорошо. согласитесь урл вида plugin://script.plugin/play/1/2/ прозаичнее чем тоже самое но в таком виде plugin://script.plugin/?action=play&show=1&episode=2

Я согласен, что в веб-приложениях, красивые УРЛ-ы удобны для пользователей и полезны для СЕО. Но в Коди их никто не видит, кроме тех, кто додумается заглянуть в лог.

[vl.maksime]

Сообщение от Roman_V_M

есть ли смысл заморачиваться? Или и так хорошо?

Меня и в таком виде устраивает. Как по мне, так даже удобней, здесь по именам параметров четко видно, какое значение за что отвечает.

Сообщение от nightik

есть. это хорошо. согласитесь урл вида plugin://script.plugin/play/1/2/ прозаичнее чем тоже самое но в таком виде plugin://script.plugin/?action=play&show=1&episode=2

Оно так красивее и занимает меньше места в *.strm файле.

Но я здесь вижу большую проблему в обратной совместимости. Для того, чтоб обеспечить загрузку сохраненных в закладках или *.strm ссылок, параметры придется вставлять только в конец. На приведенном примере, для ссылки "plugin://script.plugin/play/1/2/", все новые параметры придется писать в конец, и не известно насколько она будет красивей после всех добавлений. А если мы добавим какой-то параметр между play и 1, то вся логика дополнения сломается.

А учитывая, что я в своих дополнениях могу пропускать необязательные параметры, то мне такой способ в корне не подходит.

[HAL9000]

Добавлю свои 5 копеек в размышления о роутинге в плагинах. Я тоже столкнулся с этой дилеммой, когда писал свою обертку (кстати, это я ворчал 5 лет назад про ужасный XBMC API ).

На самом деле, абсолютно безразлично как будут выглядеть пути. Действительно, кроме Kodi их никто не видит. В своей обертке я вообще все упаковываю в JSON и уже его передаю в путь. И единственная проблема, которую я обнаружил (но так и забил на нее) – это то, что Kodi запоминает настройки сортировки, вида отображения (список, иконки и т.д.) и тому подобное на основе пути. Поэтому, если меняется расположение параметров в пути после "?", то для Kodi это новая страница и пользователю нужно заново выставлять вид отображения (например). Если использовать не параметрический URL, а ЧПУ, то проблема никуда не девается. Поэтому, повторюсь, абсолютно плевать как выглядит путь в Kodi.
И еще – сокращение нескольких байт в STRM – это экономия на спичках.

Как бы поступил я, если бы свою балалайку начинал писал сегодня?

Я бы разделил роутинг на 2 части.
Одна - перманентная. ЧПУ-вида (а можно и с параметрами). По ней я бы вызывал нужный класс-обработчик.
Вторая – переменная. В ней бы я передавал все те параметры, которые не меняли бы класс-обработчик (например – номер страницы при листании большого списка). Эти переменные не нужно совать в путь. Тогда, например, при перелистывании страниц все настройки отображения не собьются – ведь Kodi будет думать, что это одна и та же страница (в пути будет только первая часть роутинга). Как передавать эти переменные параметры (если не через путь)? Да любым способом. Я об этом плотно не думал, но можно например через сохранения их во временный файл.

Как-то так...