Каждый автор так или иначе снабжает свои скрипты метаинформацией, такой как название, описание, версия, автор, тема обсуждения на форуме, и т. п.
Сейчас эта информация может содержаться где угодно: в комментариях, или в каком-то диалоге, или в справке.
Естественно централизовано посмотреть её не получится.
Но раз каждый скрипт в любом случае содержит какую-то метаинформацию, то почему бы не заполнять её стандартизировано?
В результате мы получим возможность управлять скриптами централизованно, и реализовать разные интересные возможности, такие как изложенные ранее: http://forum.farmanager.com/viewtopic.p ... 66#p121966
Представляю экспериментальную реализацию некоторых идей:
Основные понятия:
Скрипт — это lua-файл. Он может содержать макросы или выполнять свои функции иным способом.
Скрипт может иметь вспомогательные файлы (cfg/lng/hlf).
Несколько скриптов могут формировать "пакет".
ScriptsBrowser.lua — утилита для работы со скриптами, запускается из меню плагинов.
main.png (24.01 KiB) Viewed 49888 times
sub-scripts.png (11.08 KiB) Viewed 49888 times
Info.png (20.01 KiB) Viewed 49888 times
help.png (25.7 KiB) Viewed 49888 times
regscript.lua — сам модуль, регистрирующий скрипты.
Должен быть подключен в _macroinit.lua: require"regscript"
Чтобы скрипт был зарегистрирован, он должен содержать примерно такой код:
local Info = Info or package.loaded.regscript or function(...) return ... end --luacheck: ignore 113/Info
local nfo = Info { _filename or ...,
name = "<name>";
id = "<unique id string>";
options = {a=1,b=2};
--etc
}
if not nfo then return nfo end
local O = nfo.options
Первая строка гарантирует что скрипт будет работать и без модуля регистрации. ... не просто троеточие, а выражение vararg, в данном случае позволяющее передать имя текущего файла.
Две последние строки тоже важны:
- проверка результата регистрации скрипта позволяет запретить выполнение (в случае несоответствия minfarversion, или когда его выполнение отключено другим образом)
- хранение собственных опций в таблице позволяет изменять их на лету в интерфейсе ScriptsBrowser а также переопределять их начальные значения (см. описание cfgscript.lua)
Все поля на данный момент опциональны, и их список открыт для обсуждения.
Пока предлагаю следующие:
name = "module: regscript.lua";
description = "collects metadata of luamacro scripts";
version = "0.1.1-alpha"; --в формате semver: http://semver.org/lang/ru/
author = "jd";
url = "http://forum.farmanager.com/viewtopic.php?p=121966#p121966";
id = "15660DC2-AE3F-41EE-8057-DC7428195908";
parent_id = ""; --id родительского скрипта
minfarversion = {3,0,0,4743,0}; --при несоответствии скрипт завершится
files = ""; --вспомогательные файлы скрипта
config = function(nfo,name) end; --функция конфигурации
help = function(nfo,name) end; --функция справки
execute = function(nfo,name) end; --функция исполняемая при запуске из ScriptBrowser
options = {}; --таблица с произвольными опциями скрипта
disabled = false; --запрет выполнения скрипта (см. ниже cfgscript.lua)
files
Задавая в поле files вспомогательные файлы скрипта, можно указывать абсолютный путь или путь относительно скрипта.
Поддерживаются переменные окружения.
Путь к Macros\scripts можно задать как ~\.
Шаблон * позволяет подставить имя скрипта, например files = "*_en.hlf;*_ru.hlf;"
options
Таблица с опциями, с указанием значений по-умолчанию. Смысл таблицы в том, что перечисленные опции можно изменить из браузера, а также переназначить во внешнем файле (см. cfgscript.lua)
функции
При запуске получают два аргумента: таблицу информации, и собственное имя в ней
Кроме того несколько полей зарезервированы для внутреннего использования: index, FileName, error, cfg.
Поле error создаётся в случае когда при загрузке обнаружены некорректные данные.
В том числе проверяются типы значений (добавляются только корректные поля).
cfgscript.lua — вспомогательный модуль, позволяющий переопределить начальные настройки скриптов не трогая их исходный код.
Настройки могут читаться либо из базы luamacro (уже работает, но ещё не реализован интерфейс для их записи), либо из заданного файла.
Чтобы прочитать их из файла, следует в _macroinit.lua поместить следующую команду: require"regscript".cfgload(fullpath)
Если fullpath не задан то используется файл Macros\scripts\scriptscfg.
Формат файла такой:
Параметр id обязателен.
Параметр disabled позволяет "отключить" скрипт.
Параметр options позволяет (пере)определить произвольные начальные опции.
Реальные примеры см. в scriptscfg.sample
cfgscript_test.lua — демонстрационный скрипт для иллюстрации того, что регистрация может быть полезна и в произвольных скриптах
Т.е. регистрировать можно не только макрофайлы из scripts, но и модули из modules, и вообще любые скрипты, например запускаемые из командной строки: lua:cfgscript_test.lua
InsertInfo.lua — вспомогательный макрос для вставки в скрипт шаблона с метаинформацией.
P.S.
Интерфейс самого модуля может быть интересен для применения в макробраузерах.
Сейчас он позволяет получить таблицу скрипта по индексу, по id, или по полному имени файла.
John Doe wrote: ↑Mon 11 Jan, 2021 15:42
Сделаю "по имени" (но в другом месте)
Вам виднее. Спасибо. Если (как говорил мой начальник) есть много лишнего времени, то было бы кузяво сделать настройку. Начальная сортировка по автору тоже была бы полезна. С запоминанием позиционирования. А если браузер открывается из редактора, в редакторе открыт скрипт и он есть в списке - позиционироваться сразу на нём Но это - если много лишнеговремени.
Вот такое не предполагалось вообще пихать в files.
Если в модулях присутствует аналогичный блок с метаинформацией, то они сами подтянуться (если конечно указан правильный parent_id).
John Doe wrote: ↑Mon 11 Jan, 2021 16:17
Если в модулях присутствует аналогичный блок с метаинформацией, то они сами подтянуться (если конечно указан правильный parent_id).
Это Вы сейчас кому писали?
1. Я не знаю, что такое метаинформация.
2. В модулях нет блока для регистрации (если имеется в виду вызов Info).
3. Я не знаю, что такое parent_id
4. Может, и не предполагалось. Но ведь работает! Удобно, как оказалось (в браузере можно в редакторе открыть модуль, это - удобно).
1. Имелся ввиду блок Info.
2. Вот именно
3. В шапке есть. И в самом ScriptsBrowser используется (см. cfgscript.lua)
4. Удобно, потому я и реализовал то, о чём скахано в предыдущем сообщении.
Да, можно и как вы, но нужно ли?
Если зачем-то всё-таки нужно, то стоит предусмотреть способ упростить указание путей.
Осталось дать определение "родительскому скрипту". Если есть модуль, есть крипт, который этот модуль использует, то какие у них родственные связи? Ну не знаю я Вашей терминологии!
По идее, отношение предок-потомок предполагает отношение "один-ко-многим". Один родитель -> много дочерних скриптов. Отношение скрипта с используемым в нём модулем никак не попадает эту классификацию. Может быть несколько скриптов, использующих один и тот же модуль. И не только его - несколько модулей. И кто из них родитель, а кто - дочка? Исторически часто мои модули вычленяются из скриптов, когда нужда в одной и той же функции появляется второй раз. Если так судить, родитель - скрипт? Т.е. в каждом модуле должны быть перечислены все скрипты, его использующие? Нонсенс. Ваш же скрипт le я использую активно (в т.ч. и для отладки).