Каждый автор так или иначе снабжает свои скрипты метаинформацией, такой как название, описание, версия, автор, тема обсуждения на форуме, и т. п.
Сейчас эта информация может содержаться где угодно: в комментариях, или в каком-то диалоге, или в справке.
Естественно централизовано посмотреть её не получится.
Но раз каждый скрипт в любом случае содержит какую-то метаинформацию, то почему бы не заполнять её стандартизировано?
В результате мы получим возможность управлять скриптами централизованно, и реализовать разные интересные возможности, такие как изложенные ранее: http://forum.farmanager.com/viewtopic.p ... 66#p121966
Представляю экспериментальную реализацию некоторых идей:
Основные понятия:
Скрипт — это lua-файл. Он может содержать макросы или выполнять свои функции иным способом.
Скрипт может иметь вспомогательные файлы (cfg/lng/hlf).
Несколько скриптов могут формировать "пакет".
ScriptsBrowser.lua — утилита для работы со скриптами, запускается из меню плагинов.
main.png (24.01 KiB) Viewed 49816 times
sub-scripts.png (11.08 KiB) Viewed 49816 times
Info.png (20.01 KiB) Viewed 49816 times
help.png (25.7 KiB) Viewed 49816 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, или по полному имени файла.
IgorZ wrote: Точно то же самое будет относиться и к алиасу - его тоже надо будет сокращать.
Человек в начале темы просил. Именно для компактного представления. А мне всё равно, обратите внимание это поле не поддерживается сейчас.
IgorZ wrote: Зачем применять громоздкое решение там, где можно обойтись простым и лёгким?
Простое и лёгкое тоже надо реализовывать, отлаживать, спустя время обнаруживать ошибки, и отлаживать снова.
Или взять готовый модуль на 10 килобайт.
IgorZ wrote: Но предполагаю, что их наличие упростит работу браузера.
Вот и я предполагаю.
Но реально в MacroBrowserAlt в ближайшее время внедрять не буду (его ещё доделать надо), поэтому пишите если что реально понадобится.
IgorZ wrote: Надо или унифицировать программный интерфейс между браузерами, или смириться с тем, что каждый браузер пакетов будет работать только со своим макробраузером, и наоборот.
Сейчас scriptbrowser поддерживает оба макробраузера, несмотря на отличие в интерфейсе.
IgorZ wrote: Предпочитаю сделать сразу, а не добавлять потом.
Это если бы наверняка знать что делать)
IgorZ wrote: Плагины, как исторически сложилось, всегда лежат в отдельной папке. У скриптов всё гораздо сложнее. И не только с местоположением, но и с расширениями файлов.
А я вот не против. Используйте любые новые поля, если они нужны для каких-то задач.
IgorZ wrote: И лучше тот интерфейс, который лучше поддерживает расширяемость. А таблица в этом смысле несоизмеримо лучше строки.
С таблицей тоже не будет сладко, и можно долго спорить что туда писать и в каком формате.
Поэтому пусть будет строка, в конце концов её очень легко заменить на таблицу когда это реально понадобится.
Если вообще понадобится, потому что пока всего предложенного можно достичь штатным путём.
IgorZ wrote: Несколько nfo в файле смотрятся и понимаются хуже, чем аккуратно оформленная вложенная таблица в единственном nfo.
А по-моему нечего там особо смотреть.
Постарался сделать всё так, чтобы не множить сущности.
И вроде бы удалось сохранить баланс между простотой и универсальностью.
IgorZ wrote: Можно также извратиться и задавать имя функции строкой, а возможные параметры ещё одной строкой: help = [[ShowHelp]], [["main"]].Так-то идея правильная. Надо только ShiftF1 и F9 задать, как для плагинов.
Хоткеи сделаю, а имя+параметры никак не получится, да и не надо, ведь можно просто обернуть всё в функцию.
Другой вопрос. Подозреваю во многих случаях в качестве help достаточно строки.
И вот тут возможны варианты: то ли допускать в это поле и строку и функцию, то ли для строкового представления завести отдельное поле, например helptxt.
Преимуществом первого варианта я считаю невозможность одновременного существования обоих сущностей.
Но может это и ничего.
Мнения?
IgorZ wrote: Точно то же самое будет относиться и к алиасу - его тоже надо будет сокращать.
Человек в начале темы просил. Именно для компактного представления. А мне всё равно, обратите внимание это поле не поддерживается сейчас.
Да мне тоже, в общем-то, если бы не один момент: которое из них считать приоритетным при выводе, если заполнены оба?
John Doe wrote:
IgorZ wrote: Зачем применять громоздкое решение там, где можно обойтись простым и лёгким?
Простое и лёгкое тоже надо реализовывать, отлаживать, спустя время обнаруживать ошибки, и отлаживать снова.
Или взять готовый модуль на 10 килобайт.
Я набросал три строчки для перевода строки в таблицу. Там практически негде допускать ошибку. Подозреваю, если использовать regex, будет ещё короче (могу накидать, если надо). Единственное - по сравнению с модулем более строгий формат строки. Но лично я считаю это достоинством.
Впрочем, охота использовать сторонний модуль - хозяин барин. Я высказываю аргументированное мнение, а не отдаю приказы.
John Doe wrote:
IgorZ wrote: Но предполагаю, что их наличие упростит работу браузера.
Вот и я предполагаю.
Но реально в MacroBrowserAlt в ближайшее время внедрять не буду (его ещё доделать надо), поэтому пишите если что реально понадобится.
Позже, наверное, точно скажу. Сейчас у меня пока только ощущение, что оно понадобится.
John Doe wrote:
IgorZ wrote: Предпочитаю сделать сразу, а не добавлять потом.
Это если бы наверняка знать что делать)
Просто хотелось бы иметь возможность по, допустим, F3, просмотреть список всех файлов, входящих в пакет, с указанием типа содержимого и/или описания. И чтоб список этот не приходилось составлять самому из кучи источников. И существенная часть моих замечаний относится как раз к тому, чтоб реализовать это в regscript наиболее удобным и наименее затратным способом.
John Doe wrote:
IgorZ wrote: Плагины, как исторически сложилось, всегда лежат в отдельной папке. У скриптов всё гораздо сложнее. И не только с местоположением, но и с расширениями файлов.
А я вот не против. Используйте любые новые поля, если они нужны для каких-то задач.
IgorZ wrote: И лучше тот интерфейс, который лучше поддерживает расширяемость. А таблица в этом смысле несоизмеримо лучше строки.
С таблицей тоже не будет сладко, и можно долго спорить что туда писать и в каком формате.
Поэтому пусть будет строка, в конце концов её очень легко заменить на таблицу когда это реально понадобится.
Если вообще понадобится, потому что пока всего предложенного можно достичь штатным путём.
То есть, скажем, вместо лоббирования изменения типа поля files на таблицу, ввести поле tfiles? Можно, конечно, но не очень красиво, на мой взгляд. Может тогда, хотя бы временно, разрешить для этого поля и стороковый, и табличный тип? Для версии, как я понял, это так и будет.
John Doe wrote:
IgorZ wrote: Несколько nfo в файле смотрятся и понимаются хуже, чем аккуратно оформленная вложенная таблица в единственном nfo.
А по-моему нечего там особо смотреть.
Постарался сделать всё так, чтобы не множить сущности.
И вроде бы удалось сохранить баланс между простотой и универсальностью.
Думаю, тут нужен крупный пакет из кучи файлов. Оформить nfo тем и другим способом. И можно будет говорить уже более предметно. А сейчас мы просто перетягиваем канат, образно говоря.
IgorZ wrote: Можно также извратиться и задавать имя функции строкой, а возможные параметры ещё одной строкой: help = [[ShowHelp]], [["main"]].Так-то идея правильная. Надо только ShiftF1 и F9 задать, как для плагинов.
Хоткеи сделаю, а имя+параметры никак не получится, да и не надо, ведь можно просто обернуть всё в функцию.
Другой вопрос. Подозреваю во многих случаях в качестве help достаточно строки.
И вот тут возможны варианты: то ли допускать в это поле и строку и функцию, то ли для строкового представления завести отдельное поле, например helptxt.
Преимуществом первого варианта я считаю невозможность одновременного существования обоих сущностей.
Но может это и ничего.
Мнения?
Насчёт обёртки в функцию - да, тоже вариант. Так что, по сути, проблемы нет.
Если речь идёт о справке, встроенной в скрипт, там текстовое поле возможно только в самом примитивном случае, когда вся справка - один кусок текста, не зависящий ни от чего. Если появляется зависимость от языка - уже могут возникнуть проблемы, а если справка контекстно-записимая или вообще на основе справки Far, то тут уже точно строкой никак не обойтись. Так что наиболее правильным вариантом считаю допускать и строку, и функцию. Для MenuItem работает, и тут сгодится. А отдельное поле приведёт к тому, что рано или поздно кто-то заполнит и то, и другое. И зачем провоцировать людей?
IgorZ wrote: Да мне тоже, в общем-то, если бы не один момент: которое из них считать приоритетным при выводе, если заполнены оба?
Имя, если укладывается в заданную ширину.
IgorZ wrote: И чтоб список этот не приходилось составлять самому из кучи источников.
О работе с пакетом как с единым целым предстоит ещё подумать. Пока мне не очень понятно, какие действия реально нужны, поэтому ни интерфейсом ни реализацией ещё не занимался.
IgorZ wrote: То есть, скажем, вместо лоббирования изменения типа поля files на таблицу, ввести поле tfiles? Можно, конечно, но не очень красиво, на мой взгляд.
Пока всё в стадии эксперимента можно о красоте не беспокоиться. А потом выберем и оставим лучший вариант.
IgorZ wrote: Для версии, как я понял, это так и будет.
В ближайшее время не собирался усложнять.
До контроля версий между компонентами пакета ещё очень и очень далеко.
SemVer тоже пока предлагаю только на уровне рекомендации, а фактически ничего ещё не парсится (хоть это и просто).
IgorZ wrote: Я набросал три строчки для перевода строки в таблицу.
И ещё три для сравнения версий, и т.д.
Потом всё отладить и получится тот же semver.lua
Посмотрите, он очень маленький.
IgorZ wrote: Думаю, тут нужен крупный пакет из кучи файлов.
Согласен, нужна практика.
Особо крупных пакетов ожидать не стоит.
А отдельное поле приведёт к тому, что рано или поздно кто-то заполнит и то, и другое.
Имхо это проблема даже проще, чем разобрать содержимое поля в зависимости от типа.
Так что не знаю даже..
P.S.
В следующей версии будет несколько изменён рекомендованный способ регистрации:
local Info = package.loaded.regscript or function(...) return ... end
local nfo = Info {... or _filename,
name = "<name>";
id = "<unique id string>";
options = {a=1,b=2};
--etc
}
if not nfo then return nfo end
local O = nfo.options
В шапке версия 0.1, описание приведено в соответствие с новыми возможностями
Изменён рекомендуемый способ регистрации
Реализовано хранение собственных настроек в таблице, для интерактивного изменения, и переопределения начальных значений без необходимости правки исходников.
Прежде всего это позволяет в простых скриптах не беспокоиться о реализации пользовательских настроек.
(собственно сейчас в этих случаях никто и не беспокоится, подобные "настройки" просто представлены константами в исходнике)
В качестве примера можно понастраивать сам scriptbrowser, а именно задать ширину столбцов.
Это можно сделать как через внешний файл (в шапке описано), так и интерактивно, для текущего сеанса (чтобы увидеть изменения необходимо переоткрыть scriptbrowser).
Для интерактивной правки предполагается наличие модуля lua explorer.
scriptbrowser: добавлены столбцы с версиями и со статусами
<‼☼?oс (скрипт второго уровня,ошибка,функции настройки и справки,опции,переопределение)
IgorZ wrote: И чтоб список этот не приходилось составлять самому из кучи источников.
О работе с пакетом как с единым целым предстоит ещё подумать. Пока мне не очень понятно, какие действия реально нужны, поэтому ни интерфейсом ни реализацией ещё не занимался.
А зря - это же IMHO самое вкусное. Действия - просмотр всего пакета, переход между файлами и пакетом. Как разработчик не отказался бы от копирования всего пакета на пассивную или временную панель, да и других (возможно, назначаемых?) действий. Пакет получается отдельной сущностью, а не описанием головного файла пакета.
Кстати, на подумать: не предусмотреть ли возможность действительно выносить описалово в отдельный .nfo файл?
Тут же допишу, чтоб все мысли в куче: история версий - может, её тоже не помешало бы каким-то образом формализовать и включить в nfo? Как вариант, в качестве отдельного файла?
John Doe wrote:
IgorZ wrote: То есть, скажем, вместо лоббирования изменения типа поля files на таблицу, ввести поле tfiles? Можно, конечно, но не очень красиво, на мой взгляд.
Пока всё в стадии эксперимента можно о красоте не беспокоиться. А потом выберем и оставим лучший вариант.
Ладно, попробую. Тогда (предварительно) будет просмотр tfiles, если его нет, то files.
John Doe wrote:
IgorZ wrote: Думаю, тут нужен крупный пакет из кучи файлов.
Согласен, нужна практика.
Особо крупных пакетов ожидать не стоит.
Я свои подключу, Вы своё, может, ещё кто заинтересуется. SimSU бы заинтересовать - это был бы прорыв! Количественный, как минимум.
John Doe wrote:
А отдельное поле приведёт к тому, что рано или поздно кто-то заполнит и то, и другое.
Имхо это проблема даже проще, чем разобрать содержимое поля в зависимости от типа.
Так что не знаю даже..
Ладно. Я так понял, helptxt будет сразу показываться, а help вызываться? Тогда получаем фактически уже 4 сходных по смыслу поля: alias, name, description, helptxt (по нарастанию длины текста).
IgorZ wrote: Действия - просмотр всего пакета, переход между файлами и пакетом.
Это ж есть изначально, хоть вероятно реализовано и не совсем так как вы имеете ввиду.
IgorZ wrote: Как разработчик не отказался бы от копирования всего пакета
Об этом думал. Ещё: отключение [макросов] всего пакета.
Пока кажется что для большинства вариантов применения достаточно завести в апи функцию, позволяющую получить общий неструктурированый список файлов.
IgorZ wrote: не предусмотреть ли возможность действительно выносить описалово в отдельный .nfo файл?
Выделить для этого отдельный файл можно и сейчас. Т.е. завести какой-нибудь package_meta.lua с описанием пакета, а остальные скрипты будут ссылаться на него в parent_id.
Но вы вероятно имели ввиду другое: собрать всю метаинформацию в один файл, а сами скрипты будут от неё свободны. Нет, мне не кажется это хорошей мыслью.
А вот генерировать сводный отчёт о пакете может быть полезно, да.
IgorZ wrote: Тогда получаем фактически уже 4 сходных по смыслу поля: alias, name, description, helptxt
Верно.
Но: alias пока не поддерживается. А насчёт helptxt пока думаю, возможно не нужна никакая специальная поддержка.
Вместо этого другая мысль: отображать в информации все поля, а не только "поддерживаемые". (вопрос в том, отображать ли полностью, как сейчас helptxt, или же по нажатию отображать развёрнуто, в диалоге)
IgorZ wrote: история версий - может, её тоже не помешало бы каким-то образом формализовать и включить в nfo?
Включить легко, хоть сейчас.
Если в виде отдельного поля, то см. замечание насчёт helptxt. Аналогичным образом можно любую информацию добавить, например лицензию.
Если отдельным файлом, то опять же, хоть сейчас в поле files. Оттуда легко открыть файл.
В следующей версии это можно будет сделать и из общего списка скриптов.
P.S.
Что касается типа содержимого.
Предлагаю не вводить новые сущности, а приравнять тип к расширению (или определять по маске).
IgorZ wrote: Действия - просмотр всего пакета, переход между файлами и пакетом.
Это ж есть изначально, хоть вероятно реализовано и не совсем так как вы имеете ввиду.
IgorZ wrote: Как разработчик не отказался бы от копирования всего пакета
Об этом думал. Ещё: отключение [макросов] всего пакета.
Пока кажется что для большинства вариантов применения достаточно завести в апи функцию, позволяющую получить общий неструктурированый список файлов.
Скажем так: я предлагаю больше использовать идеологию ООП. В приложении к Луа это значит, что у нас есть одна таблица (возможно, сложной структуры), описывающая весь пакет. Если список входящих файлов будет выдаваться функцией-полем этой таблицы, почему бы и нет?
John Doe wrote:
IgorZ wrote: не предусмотреть ли возможность действительно выносить описалово в отдельный .nfo файл?
Выделить для этого отдельный файл можно и сейчас. Т.е. завести какой-нибудь package_meta.lua с описанием пакета, а остальные скрипты будут ссылаться на него в parent_id.
Но вы вероятно имели ввиду другое: собрать всю метаинформацию в один файл, а сами скрипты будут от неё свободны. Нет, мне не кажется это хорошей мыслью.
А вот генерировать сводный отчёт о пакете может быть полезно, да.
В обязательном порядке - нет, не предлагаю. Но наряду с *.lua сканировать *.nfo, предполагая внутри наличие nfo - вот над этим подумать.
John Doe wrote:
IgorZ wrote: Тогда получаем фактически уже 4 сходных по смыслу поля: alias, name, description, helptxt
Верно.
Но: alias пока не поддерживается. А насчёт helptxt пока думаю, возможно не нужна никакая специальная поддержка.
Вместо этого другая мысль: отображать в информации все поля, а не только "поддерживаемые". (вопрос в том, отображать ли полностью, как сейчас helptxt, или же по нажатию отображать развёрнуто, в диалоге)
Второй вариант, разумеется, а то наплодит кто-нибудь 100500 полей, и выводи их. LuaExplorer для этого, думаю, идеально подходит. Если же его нет, просто выводить список названий пользовательских полей.
John Doe wrote:
IgorZ wrote: история версий - может, её тоже не помешало бы каким-то образом формализовать и включить в nfo?
Включить легко, хоть сейчас.
Если в виде отдельного поля, то см. замечание насчёт helptxt. Аналогичным образом можно любую информацию добавить, например лицензию.
Если отдельным файлом, то опять же, хоть сейчас в поле files. Оттуда легко открыть файл.
В следующей версии это можно будет сделать и из общего списка скриптов.
Может, и так. Но я прикидывал насчёт некоторой формализации структуры истории и, соответственно, расширенных возможностей вывода. Может, и лишку, конечно.
John Doe wrote:Что касается типа содержимого.
Предлагаю не вводить новые сущности, а приравнять тип к расширению (или определять по маске).
Невозможно практически. Навскидку: файл с настройками может быть .lua, .cfg, .ini, без расширения, .lua_cfg, .lua.cfg... У кого на что фантазии хватит - обязательной стандартизации-то нет. С языковыми почти та же история, усугубляемая тем, что там ещё запросто могут всплыть расширения, включающие "rus", "eng" и другие языковые сокращения. В общем, отдельное поле в данном случае и проще, и надёжнее. А бояться, что автор поленится заполнить поле - так он и вообще всё nfo ещё скорее поленится заполнять.
P. S. Имеет ли смысл вводить поле - адрес данных скрипта в БД LuaMacro? Просто, если оно есть, то имеет смысл сделать переход по ссылке - скажем, с помощью DBEdit. Он, правда, пока не вызывается как модуль, но это нетрудно добавить.
IgorZ wrote: В приложении к Луа это значит, что у нас есть одна таблица (возможно, сложной структуры), описывающая весь пакет.
Я не знаю нужна ли такая сводная таблица на практике, но если да, то она может быть построена программно, а исходные таблицы при этом стоит оставить максимально простыми.
IgorZ wrote: Но наряду с *.lua сканировать *.nfo, предполагая внутри наличие nfo - вот над этим подумать.
Рекурсивно обходя содержимое scripts?
IgorZ wrote: Второй вариант, разумеется, а то наплодит кто-нибудь 100500 полей, и выводи их.
И выведу)
Пока реализовал так: если количество строк меньше заданного, то выводится полный текст, иначе только первая строка.
IgorZ wrote: Но я прикидывал насчёт некоторой формализации структуры истории
В дальней перспективе, когда мы с вами реализуем автообновление скриптов, это может быть полезно.
IgorZ wrote: У кого на что фантазии хватит - обязательной стандартизации-то нет.
Если нужна, то почему нет. Запросто.
IgorZ wrote: А бояться, что автор поленится заполнить поле - так он и вообще всё nfo ещё скорее поленится заполнять.
Автор сразу правильно назовёт файл, и это избавит и его и нас от лишней работы.
IgorZ wrote: Имеет ли смысл вводить поле - адрес данных скрипта в БД LuaMacro?
Хорошая мысль.
Поле можно назвать dbkey.
А как будем передавать адрес? строкой? таблицей?
Хотелось бы также получить отзывы по способу регистрации скрипта (помимо структуры таблицы).
И отзывы/пожелания по работе с настройками.
Пока в планах добавить возможность автосохранения отдельных (указанных) опций в базе, и справку по самим опциям.
(Речь о произвольных собственных опциях скриптов, тех что задаются в поле options.)
John Doe wrote:она может быть построена программно
Собственно, пока суть да дело, я уже так и сделал.
John Doe wrote:
IgorZ wrote: Но наряду с *.lua сканировать *.nfo, предполагая внутри наличие nfo - вот над этим подумать.
Рекурсивно обходя содержимое scripts?
Другого способа не вижу. Так что или так, или никак.
John Doe wrote:
IgorZ wrote: Но я прикидывал насчёт некоторой формализации структуры истории
В дальней перспективе, когда мы с вами реализуем автообновление скриптов, это может быть полезно.
Тогда пока отложить на будущее?
John Doe wrote:
IgorZ wrote: У кого на что фантазии хватит - обязательной стандартизации-то нет.
Если нужна, то почему нет. Запросто.
И как заставить всех абсолютно авторов? Добавить код, рекурсивно обходящий папку Macros и удаляющий все файлы с "некошерными" расширениями? Ибо альтернативой - только добрая воля (субстанция куда более редкая, чем хотелось бы).
John Doe wrote:
IgorZ wrote: А бояться, что автор поленится заполнить поле - так он и вообще всё nfo ещё скорее поленится заполнять.
Автор сразу правильно назовёт файл, и это избавит и его и нас от лишней работы.
А какое расширение - правильное? Скажем, если у файла типичная .ini структура, то и расширение напрашивается аналогичное. А если внутри Луа-код, то и расширение логично поставить .lua. Но при этом для соответствующего скрипта и то, и другое - файл настроек. Говоря научно, тип файла - следующий, более высокий уровень абстракции (описывающий назначение содержимого файла) в сравнении с его расширением (описывающим структуру внутреннего содержимого), и именно он нас и интересует.
И ещё одно соображение. Если, к примеру и языковые настройки, и справка находятся в одном файле (у самого в некоторых скриптах так), то отдельное поле типа позволит явно это указать, а ориентирование по расширению окажется бесполезно.
John Doe wrote:
IgorZ wrote: Имеет ли смысл вводить поле - адрес данных скрипта в БД LuaMacro?
Хорошая мысль.
Поле можно назвать dbkey.
А как будем передавать адрес? строкой? таблицей?
Строкой. В DBEdit есть парсер, так что надобности в более сложном варианте нет. Строка должна быть такой:
"[LOCAL|GLOBAL](по умолчанию GLOBAL)[<разделитель><элемент пути>]..." Разделителем сейчас \n (максимально радикально), так что это обсуждаемо, но крайне желателен символ, невозможный в имени переменной.
John Doe wrote:Хотелось бы также получить отзывы по способу регистрации скрипта (помимо структуры таблицы).
Я что-то крупное не заметил? Реализован ещё какой-то способ регистрации, кроме nfo-таблиц? Или речь о предлагаемых на будущее вариантах? Что-то в упор не помню, чтоб это обсуждалось.
John Doe wrote:И отзывы/пожелания по работе с настройками.
Пока в планах добавить возможность автосохранения отдельных (указанных) опций в базе, и справку по самим опциям.
(Речь о произвольных собственных опциях скриптов, тех что задаются в поле options.)
Пока вплотную этим не успел заняться, поэтому ничего особо не скажу, вроде всё по уму. Единственно: хотелось бы видеть это независимым от regscript механизмом. Это возможно?
IgorZ wrote: И как заставить всех абсолютно авторов? Добавить код, рекурсивно обходящий папку Macros и удаляющий все файлы с "некошерными" расширениями? Ибо альтернативой - только добрая воля (субстанция куда более редкая, чем хотелось бы).
Не будем заставлять)
Если автор позаботился о регистрации скрипта, значит увидел для себя какую-то в этом пользу, и (будем надеяться) предварительно изучил прилагающуюся документацию.
IgorZ wrote: А если внутри Луа-код, то и расширение логично поставить .lua. Но при этом для соответствующего скрипта и то, и другое - файл настроек.
Файлы с расширением lua в папке scripts это скрипты. Они могут себя зарегистрировать сами, в частности используя и специальное поле для типа.
Аналогично, они могут быть зарегистрированы и из основного скрипта дополнительным вызовом Info.
И третий вариант, тип "настройки" например может быть определён и маской вида *.cfg.*
(В следующей версии я уже ввёл типы, пока только в browser)
IgorZ wrote: Если, к примеру и языковые настройки, и справка находятся в одном файле (у самого в некоторых скриптах так), то отдельное поле типа позволит явно это указать, а ориентирование по расширению окажется бесполезно.
Используя Info вы можете предусмотреть и такую гипотетическую ситуацию, если это необходимо.
IgorZ wrote: крайне желателен символ, невозможный в имени переменной.
Знаю только один такой \0.
Ну а на практике вряд ли есть необходимость использовать даже слэш.
С другой стороны, использование таблицы позволило бы не делать никаких допущений о практике.