ScriptsBrowser — управление скриптами [экспериментально]

Здесь обсуждается всё, что касается макросов.
User avatar
John Doe
Бюрократ
Posts: 11042
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

ScriptsBrowser — управление скриптами [экспериментально]

Postby John Doe » Tue 09 Aug, 2016 16:10

Каждый автор так или иначе снабжает свои скрипты метаинформацией, такой как название, описание, версия, автор, тема обсуждения на форуме, и т. п.
Сейчас эта информация может содержаться где угодно: в комментариях, или в каком-то диалоге, или в справке.
Естественно централизовано посмотреть её не получится.

Но раз каждый скрипт в любом случае содержит какую-то метаинформацию, то почему бы не заполнять её стандартизировано?
В результате мы получим возможность управлять скриптами централизованно, и реализовать разные интересные возможности, такие как изложенные ранее: John Doe @ Скрипты: система их названий и описаний

Представляю экспериментальную реализацию некоторых идей:
Основные понятия:
  • Скрипт — это lua-файл. Он может содержать макросы или выполнять свои функции иным способом.
  • Скрипт может иметь вспомогательные файлы (cfg/lng/hlf).
  • Несколько скриптов могут формировать "пакет".
ScriptsBrowser.lua — утилита для работы со скриптами, запускается из меню плагинов.

regscript.lua — сам модуль, регистрирующий скрипты.
Все поля на данный момент опциональны, и их список открыт для обсуждения.
Пока предлагаю следующие:


cfgscript.lua — вспомогательный модуль, позволяющий переопределить начальные настройки скриптов не трогая их исходный код.

cfgscript_test.lua — демонстрационный скрипт для иллюстрации того, что регистрация может быть полезна и в произвольных скриптах

InsertInfo.lua — вспомогательный макрос для вставки в скрипт шаблона с метаинформацией.

P.S.
Интерфейс самого модуля может быть интересен для применения в макробраузерах.
Сейчас он позволяет получить таблицу скрипта по индексу, по id, или по полному имени файла.
Attachments
scriptbrowser02.7z
(10.12 KiB) Downloaded 41 times
Last edited by John Doe on Fri 26 Aug, 2016 16:49, edited 1 time in total.

User avatar
HaRT
Moderator
Posts: 7918
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 65 times
Been thanked: 94 times

Скрипты: система их названий и описаний

Postby HaRT » Tue 09 Aug, 2016 16:30

John Doe, поясните, пжлст, про parent/subscripts.
Кстати, слово subscript имеет устоявшееся другое значение, т.ч. предлагаю хотя бы через дефис: “sub-scripts”.
Last edited by HaRT on Fri 26 Aug, 2016 20:34, edited 1 time in total.
Фар есть инструмент, а не нянька. © 2009 DrKnS

User avatar
John Doe
Бюрократ
Posts: 11042
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

Скрипты: система их названий и описаний

Postby John Doe » Tue 09 Aug, 2016 17:06

HaRT wrote:Source of the post parent/subscripts.
Скрипты можно организовывать иерархически.
Если есть несколько скриптов с одним parent_id, то для родительского скрипта они будут под-скриптами.

Shmuel
Posts: 4957
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 11 times
Been thanked: 125 times

Скрипты: система их названий и описаний

Postby Shmuel » Tue 09 Aug, 2016 17:15

Code: Select all

╔════════════════════════════════════ LuaMacro ═════════════════════════════════════╗
║ ...ta\Far Manager\Profile\Macros\scripts\scriptsbrowser.lua:1: regscript required ║
╟───────────────────────────────────────────────────────────────────────────────────╢
║                                  { OK } [ Edit ]                                  ║
╚═══════════════════════════════════════════════════════════════════════════════════╝

User avatar
John Doe
Бюрократ
Posts: 11042
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

Скрипты: система их названий и описаний

Postby John Doe » Tue 09 Aug, 2016 20:01

Shmuel
John Doe wrote:Source of the post regscript.lua — сам модуль, регистрирующий скрипты.
Должен быть подключен в _macroinit.lua: require"regscript"

Shmuel
Posts: 4957
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 11 times
Been thanked: 125 times

Скрипты: система их названий и описаний

Postby Shmuel » Tue 09 Aug, 2016 20:08

Да, спасибо, уже и сам разобрался. Устал сегодня.

IgorZ
Posts: 427
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 4 times
Been thanked: 6 times

Скрипты: система их названий и описаний

Postby IgorZ » Wed 10 Aug, 2016 10:35

John Doe wrote:Все поля на данный момент опциональны, и их список открыт для обсуждения.
Пока предлагаю следующие:

Вопросы, замечания, предложения.
  1. Поле name: свободное значение, как я смотрю? Тогда чем оно отличается от description?
  2. Предлагаю ввести поле type, содержащее тип файла (macros, events, module, config, lng, help...). Если содержимое смешанное, в type указывать несколько значений через запятую, например "lng,help".
  3. Также предлагаю ввести поле lang (ru,en...) для файлов с данными локализации.
  4. Для вспомогательных файлов пакета, возможно, имеет смысл ввести поле minpackageversion для контроля версий внутри пакета.
  5. Чуть не забыл: таблица relations с указанием сторонних пакетов, которые обязательно или опицонально требуются для работы данного пакета. К примеру, для LuaManager это могло бы выглядеть так:

    Code: Select all

    relations = {
    "rebind"={id="id пакета", minpackageversion="1", importance="optional"},
    "Lua Explorer"={id="id пакета", importance="optional"}
    }
  6. Поле files лучше, на мой взгляд сделать таблицей с записями вида имя_файла=тип. Или даже имя_файла=nfo_таблица. Имя файла указывается с путём относительно файла, содержащего таблицу (я так понимаю, она содержится только в главном файле). Предусмотреть возможность использовать макрос, обозначающий имя головного файла, например [".\?Rus.lng"] = {type="lng", lang="ru", description = "russian localisation data", minpackageversion= "3.1.2"}, где "?" - имя главного файла.
  7. Не совсем понятны поля config и help. Это функции, выводящие справку и конфигурацию самих скриптов, имеющуюся независимо от regscript, или что-то другое?

Smitis
Posts: 1432
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 9 times
Been thanked: 21 times
Contact:

Скрипты: система их названий и описаний

Postby Smitis » Wed 10 Aug, 2016 13:26

IgorZ wrote:таблица relations с указанием сторонних пакетов, которые обязательно или опицонально требуются для работы данного пакета.
Имхо, лучше название dependencies
Разум когда-нибудь победит.

User avatar
John Doe
Бюрократ
Posts: 11042
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

Скрипты: система их названий и описаний

Postby John Doe » Wed 10 Aug, 2016 15:16

IgorZ wrote:Source of the post Поле name: свободное значение, как я смотрю? Тогда чем оно отличается от description?
Тем же чем имя плагина отличается от его описания. F11, F3
Имя короткое, Описание подлиннее.
Где-то просили ещё alias, как сокращённое имя. Например так

IgorZ wrote:Source of the post Предлагаю ввести поле type, содержащее тип файла
А как это предлагается применять?
Наличие макросов выясняется на раз.
А что с остальным делать?
Если просто посмотреть, то в описание можно.
Если для какого-то анализа, то для какого именно?

IgorZ wrote:Source of the post Также предлагаю ввести поле lang (ru,en...) для файлов с данными локализации.
Тот же вопрос. Что делать с этим полем?
(Локализовать саму метаинформацию да, смысл есть, и в todo записано)

IgorZ wrote:Source of the post Для вспомогательных файлов пакета, возможно, имеет смысл ввести поле minpackageversion для контроля версий внутри пакета.
Смысл есть, типа parent_minversion. Но для практического применения необходимо стандартизировать способ указания версии. Как вам https://github.com/kikito/semver.lua ?

IgorZ wrote:Source of the post Чуть не забыл: таблица relations с указанием сторонних пакетов, которые обязательно или опицонально требуются для работы данного пакета. К примеру, для LuaManager это могло бы выглядеть так:
И здесь у меня к вам тот же вопрос: зачем?
Автор должен иметь от этого прямую выгоду, иначе он просто не будет заполнять все эти поля. И будет прав.

IgorZ wrote:Source of the post Не совсем понятны поля config и help. Это функции, выводящие справку и конфигурацию самих скриптов, имеющуюся независимо от regscript, или что-то другое?
Да, именно независимо.
(Про конфигурацию вы верно заметили, в следующей версии её будет предоставлять regscript).
P.S.
Хотя сейчас мне это уже не кажется особенно удобным: метаинформация у нас содержится в начале скрипта, а значит функцию придётся определять слишком рано.

User avatar
John Doe
Бюрократ
Posts: 11042
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

Скрипты: система их названий и описаний

Postby John Doe » Wed 10 Aug, 2016 15:28

IgorZ wrote:Source of the post например [".\?Rus.lng"] = {type="lng", lang="ru", description = "russian localisation data", minpackageversion= "3.1.2"}
Шаблоны несложно добавить.
А всё остальное я просто пока не понимаю зачем.
Сейчас тупо строка, потому что достаточно.

Кстати нигде не написано, в скриптбраузере информация о скрипте это меню, где многие пункты кликабельны.
В частности выбрав files мы откроем меню из списка файлов, где недоступные будут серыми, а остальные можно выбрать и перейти.
В этом сейчас практический смысл.

Ваши предложения мне разумеется тоже интересны, но полезность должна определяться практикой.
Наворачивать что-то наперёд, авось пригодится я считаю неполезным

P.S.
Хочу пояснить для чего вообще это отдельное поле files.
Если подумать, то многие вспомогательные файлы, будучи сами lua-скриптами (независимо от фактического расширения), могут регистрировать себя самостоятельно.
А значит в files имеет смысл указывать только нескрипты.

И даже их сейчас можно зарегистрировать отдельно, добавив в основной скрипт несколько вызовов Info.
При необходимости можно несколько усовершенствовать, и это имхо будет лучше, чем пихать таблицу в таблицу таблиц.

User avatar
John Doe
Бюрократ
Posts: 11042
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

Скрипты: система их названий и описаний

Postby John Doe » Wed 10 Aug, 2016 15:51

IgorZ
Хотелось бы ещё отдельно обсудить две вещи, и ваше мнение как с автора LuaManager особенно важно.
  • разделение функций между regscript и scriptbrowser
    Сначала вся иерархия (родителей и под-скриптов) строилась в regscript (и была доступна прямо из таблицы скрипта, как поля subscripts и parents).
    Сейчас я сознательно упростил regscript до минимума, вынеся всю "аналитику" в scriptbrowser.
  • Как лучше осуществить интеграцию с макробраузерами пока что мне не очень понятно
    Какая информация нужна макробраузерам?
    Должны ли они всё получать от regscript, или для части функций имеет смысл использовать scriptbrowser (чтобы максимально избавить макробраузеры от реализации собственных велосипедов)

    Пока что мне видится так, что оба скрипта будут иметь отдельный интерфейс.
    Или (для удобства) же всё можно объединить в один интерфейс.

IgorZ
Posts: 427
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 4 times
Been thanked: 6 times

Скрипты: система их названий и описаний

Postby IgorZ » Thu 11 Aug, 2016 09:18

Smitis wrote:
IgorZ wrote:таблица relations с указанием сторонних пакетов, которые обязательно или опицонально требуются для работы данного пакета.
Имхо, лучше название dependencies
Можно и так. Наверное, даже лучше, точнее передаёт смысл.

User avatar
John Doe
Бюрократ
Posts: 11042
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

Скрипты: система их названий и описаний

Postby John Doe » Thu 11 Aug, 2016 09:36

Обращаю внимание, что в настоящий момент считываются и запоминаются любые поля.
Т.о. со своими идеями можно экспериментировать не отходя от кассы

IgorZ
Posts: 427
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 4 times
Been thanked: 6 times

Скрипты: система их названий и описаний

Postby IgorZ » Thu 11 Aug, 2016 10:42

John Doe wrote:
IgorZ wrote:Source of the post Поле name: свободное значение, как я смотрю? Тогда чем оно отличается от description?
Тем же чем имя плагина отличается от его описания. F11, F3
Имя короткое, Описание подлиннее.
Где-то просили ещё alias, как сокращённое имя. Например так
Особого смысла не вижу, но ради однообразия с плагинами - возможно, имеет смысл. А вот алиасы представляются мне совсем уж излишней сущностью. Алиас команды имеет смысл для сокращения часто повторяющегося набираемого вручную текста. Имя пакета разве будет набираться вручную?
John Doe wrote:
IgorZ wrote:Source of the post Предлагаю ввести поле type, содержащее тип файла
А как это предлагается применять?
Наличие макросов выясняется на раз.
А что с остальным делать?
Если просто посмотреть, то в описание можно.
Если для какого-то анализа, то для какого именно?
Например, для быстрой сортировки или фильтрации нужного типа файлов без дорогостоящей и не всегда возможной операции потрошения их содержимого. Причём, те же языковые файлы могут быть в самом разном формате и иметь разное расширение, но при этом одну и ту же суть. Тут, наверное, нужно уточнить: в первую очередь описание типа необходимо для предлагаемой таблицы files, а в информации о самом файле это не столь актуально, но тоже удобно.
John Doe wrote:
IgorZ wrote:Source of the post Также предлагаю ввести поле lang (ru,en...) для файлов с данными локализации.
Тот же вопрос. Что делать с этим полем?
(Локализовать саму метаинформацию да, смысл есть, и в todo записано)
А это логичное продолжение идеи с типами файлов. Кстати, можно, наверное, обойтись без отдельного поля, а ввести уточняющие суффиксы, например: "lng:ru", "help:en". Или даже "lng:en:ru", если в одном файле собраны несколько языковых локализаций.
John Doe wrote:
IgorZ wrote:Source of the post Для вспомогательных файлов пакета, возможно, имеет смысл ввести поле minpackageversion для контроля версий внутри пакета.
Смысл есть, типа parent_minversion. Но для практического применения необходимо стандартизировать способ указания версии. Как вам https://github.com/kikito/semver.lua ?
Посмотрел. Мне кажется, {версия, подверсия, правка, сборка[,статус(альфа,бета,релиз и т. п.)]} и привычней, и удобней в работе, и проще формализуется и верифицируется, и не требует сторонних модулей.
John Doe wrote:
IgorZ wrote:Source of the post Чуть не забыл: таблица relations с указанием сторонних пакетов, которые обязательно или опицонально требуются для работы данного пакета. К примеру, для LuaManager это могло бы выглядеть так:
И здесь у меня к вам тот же вопрос: зачем?
Автор должен иметь от этого прямую выгоду, иначе он просто не будет заполнять все эти поля. И будет прав.
Автор (любой) вообще в большинстве случаев не имеет прямой выгоды от выпуска и поддержки скриптов или плагинов. Тем не менее, авторы выкладывают, осуществляют поддержку, оформляют аккуратно шапку темы... Так что не всё так однозначно.
Тем не менее, определённая выгода есть. Информацию о зависимости от других разработок автор всё равно вынужден публиковать, а пользователь искать. И стандартизация этой информации (то есть, не дополнительная писанина, а формализация имеющейся) облегчит жизнь им обоим.
John Doe wrote:
IgorZ wrote:Source of the post Не совсем понятны поля config и help. Это функции, выводящие справку и конфигурацию самих скриптов, имеющуюся независимо от regscript, или что-то другое?
Да, именно независимо.
(Про конфигурацию вы верно заметили, в следующей версии её будет предоставлять regscript).
P.S.
Хотя сейчас мне это уже не кажется особенно удобным: метаинформация у нас содержится в начале скрипта, а значит функцию придётся определять слишком рано.
Насчёт "слишком рано": local имя_будущей_функции не принесёт особого вреда. Хоть и будет смотреться в ряде случаев не очень красиво. Можно также извратиться и задавать имя функции строкой, а возможные параметры ещё одной строкой: help = [[ShowHelp]], [["main"]].Так-то идея правильная. Надо только ShiftF1 и F9 задать, как для плагинов.
John Doe wrote:
IgorZ wrote:Source of the post например [".\?Rus.lng"] = {type="lng", lang="ru", description = "russian localisation data", minpackageversion= "3.1.2"}
Шаблоны несложно добавить.
А всё остальное я просто пока не понимаю зачем.
Сейчас тупо строка, потому что достаточно.
Тип и язык - для однозначной идентификации содержимого файла. Это нужно не автору скрипта (он и так всё о нём знает), а пользователю, чтобы в браузере можно было просто и однозначно манипулировать этими файлами. Иначе, как я уже писал выше, в многих случаях определить тип содержимого нельзя без его просмотра и анализа человеком. Описание - необязательное поле, для того же, что и все остальные описания. Требуемая версия - для контроля версий, тоже, в принципе, необязательное поле. Но в некоторых случаях удобное. Хотя правильнее всего было бы закинуть его в сам файл. К сожалению, в ряде случаев это невозможно.
И да, таблица - потому что с ней удобнее работать программно. И проще расписать всё визуально красиво, чем в случае строки. И намного проще расширить функциональность, если это понадобится позже.
John Doe wrote:Хочу пояснить для чего вообще это отдельное поле files.
Если подумать, то многие вспомогательные файлы, будучи сами lua-скриптами (независимо от фактического расширения), могут регистрировать себя самостоятельно.
А значит в files имеет смысл указывать только нескрипты.
И даже их сейчас можно зарегистрировать отдельно, добавив в основной скрипт несколько вызовов Info.
При необходимости можно несколько усовершенствовать, и это имхо будет лучше, чем пихать таблицу в таблицу таблиц.
Нужно, наверное, пояснить. То, что я описывал - это с точки зрения, в первую очередь, будущего браузерописателя. То есть, такой я хотел бы видеть структуру, получаемую от модуля. Будет она браться целиком из nfo или собираться из кусочков в памяти - вопрос не столь важный. Тем не менее, замечу:
  1. Если в головном файле в nfo будут перечислены все файлы, входящие в пакет, пользователю будет удобнее пользоваться информацией (автору пакета, повторюсь, эта информация вообще до лампочки).
  2. Несколько nfo в одном файле кажутся мне идеологически неверными и профанирующими саму идею: навскидку, я изменю файл, а хранящаяся в другом месте nfo останется неизменной. Или же, я открываю файл и не вижу, к какому пакету он относится, потому что его nfo в другом файле. Или на каждый чих запускать браузер? И вообще, есть хороший метод: любую идею доводим до логического завершения и смотрим, что получится. Получается отдельный файл .nfo, в котором хранится вся информация по пакету и вхоящим в него файлам. Немного не то, что задумывалось, не так ли?
  3. Многоуровневая структура данных при аккуратном оформлении красива, наглядна и удобна.

User avatar
John Doe
Бюрократ
Posts: 11042
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

Скрипты: система их названий и описаний

Postby John Doe » Thu 11 Aug, 2016 10:59

IgorZ wrote:Source of the post А вот алиасы представляются мне совсем уж излишней сущностью.
Ранее в теме обсуждалось.
Смысл: сокращённое наименование скрипта, с целью компактного представления в дополнительной колонке макробраузера.
IgorZ wrote:Source of the post {версия, подверсия, правка, сборка[,статус(альфа,бета,релиз и т. п.)]} и привычней, и удобней в работе
По факту сам фар использует одно единственное число. И если вдруг когда-нибудь будет новый слом апи, то задействуется второе.
Плагины же используют кто во что гаразд.
В этом плане семантическое версионирование меня привлекает тем, что однозначно определяет порядок когда следует увеличивать каждую часть версии.
А маленький дополнительный модуль, идущий в составе пакета никому не повредит.

IgorZ
Posts: 427
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 4 times
Been thanked: 6 times

Скрипты: система их названий и описаний

Postby IgorZ » Thu 11 Aug, 2016 11:13

John Doe wrote:Source of the post Хотелось бы ещё отдельно обсудить две вещи, и ваше мнение как с автора LuaManager особенно важно.
  • разделение функций между regscript и scriptbrowser
    Сначала вся иерархия (родителей и под-скриптов) строилась в regscript (и была доступна прямо из таблицы скрипта, как поля subscripts и parents).
    Сейчас я сознательно упростил regscript до минимума, вынеся всю "аналитику" в scriptbrowser.
Мне кажется, regscript должен сводить всю информацию из всех файлов в единую таблицу с формализованной структурой, выявлять ошибки в данных, дополнять таблицу дополнительными к содержащимся в nfo данными (пример - уже имеющееся FileName), и на этом всё. Браузер должен полагаться, что полученная информация корректна, в строгом соответствии с оговорённым форматом структурирована и, насколько возможно, полна. Остальное - его работа. Как пример получаемой информации - данные, получаемые с помощью mf.GetMacroCopy.
John Doe wrote:
  • Как лучше осуществить интеграцию с макробраузерами пока что мне не очень понятно
    Какая информация нужна макробраузерам?
    Должны ли они всё получать от regscript, или для части функций имеет смысл использовать scriptbrowser (чтобы максимально избавить макробраузеры от реализации собственных велосипедов)
    Пока что мне видится так, что оба скрипта будут иметь отдельный интерфейс.
    Или (для удобства) же всё можно объединить в один интерфейс.
То есть, использовать ли scriptbrowser в качестве дополнительного модуля, содержащего функции обработки данных, полученных от regscript? Если останется возможность использовать regscript самостоятельно - почему бы и нет? Тут я вижу некоторую аналогию с тройкой "сервер БД - сервер приложений - клиент".
А велосипед - понятие относительное. Если, скажем, я добавлю поддержку regscript непосредственно в LuaManager (я пока не определился окончательно, как лучше сделать), то использование scriptbrowser может оказаться как бы не бОльшим велосипедом, чем использование уже имеющегося в LuaManager функционала. Общий принцип мне представляется таким: внешние функции обработки данных могут быть полезны, функции, относящиеся к форматированию и вывод информации, как правило, должны быть свои.


Return to “Обсуждение макросов”

Who is online

Users browsing this forum: No registered users and 2 guests