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

Здесь обсуждается всё, что касается макросов.
User avatar
John Doe
Бюрократ
Posts: 11048
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 10 times
Been thanked: 63 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 43 times
Last edited by John Doe on Fri 26 Aug, 2016 16:49, edited 1 time in total.

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

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

Postby John Doe » Fri 12 Aug, 2016 15:02

Latest post of the previous page:

IgorZ wrote:Source of the post Точно то же самое будет относиться и к алиасу - его тоже надо будет сокращать.
Человек в начале темы просил. Именно для компактного представления. А мне всё равно, обратите внимание это поле не поддерживается сейчас.

IgorZ wrote:Source of the post Зачем применять громоздкое решение там, где можно обойтись простым и лёгким?
Простое и лёгкое тоже надо реализовывать, отлаживать, спустя время обнаруживать ошибки, и отлаживать снова.
Или взять готовый модуль на 10 килобайт.

IgorZ wrote:Source of the post Но предполагаю, что их наличие упростит работу браузера.
Вот и я предполагаю.
Но реально в MacroBrowserAlt в ближайшее время внедрять не буду (его ещё доделать надо), поэтому пишите если что реально понадобится.

IgorZ wrote:Source of the post Надо или унифицировать программный интерфейс между браузерами, или смириться с тем, что каждый браузер пакетов будет работать только со своим макробраузером, и наоборот.
Сейчас scriptbrowser поддерживает оба макробраузера, несмотря на отличие в интерфейсе.

IgorZ wrote:Source of the post Предпочитаю сделать сразу, а не добавлять потом.
Это если бы наверняка знать что делать)

IgorZ wrote:Source of the post Плагины, как исторически сложилось, всегда лежат в отдельной папке. У скриптов всё гораздо сложнее. И не только с местоположением, но и с расширениями файлов.
А я вот не против. Используйте любые новые поля, если они нужны для каких-то задач.

IgorZ wrote:Source of the post И лучше тот интерфейс, который лучше поддерживает расширяемость. А таблица в этом смысле несоизмеримо лучше строки.
С таблицей тоже не будет сладко, и можно долго спорить что туда писать и в каком формате.
Поэтому пусть будет строка, в конце концов её очень легко заменить на таблицу когда это реально понадобится.
Если вообще понадобится, потому что пока всего предложенного можно достичь штатным путём.

IgorZ wrote:Source of the post Несколько nfo в файле смотрятся и понимаются хуже, чем аккуратно оформленная вложенная таблица в единственном nfo.
А по-моему нечего там особо смотреть.
Постарался сделать всё так, чтобы не множить сущности.
И вроде бы удалось сохранить баланс между простотой и универсальностью.

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

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

Postby John Doe » Sat 13 Aug, 2016 14:18

IgorZ wrote:Source of the post Можно также извратиться и задавать имя функции строкой, а возможные параметры ещё одной строкой: help = [[ShowHelp]], [["main"]].Так-то идея правильная. Надо только ShiftF1 и F9 задать, как для плагинов.
Хоткеи сделаю, а имя+параметры никак не получится, да и не надо, ведь можно просто обернуть всё в функцию.

Другой вопрос. Подозреваю во многих случаях в качестве help достаточно строки.
И вот тут возможны варианты: то ли допускать в это поле и строку и функцию, то ли для строкового представления завести отдельное поле, например helptxt.
Преимуществом первого варианта я считаю невозможность одновременного существования обоих сущностей.
Но может это и ничего.
Мнения?

IgorZ
Posts: 436
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Postby IgorZ » Mon 15 Aug, 2016 09:58

John Doe wrote:
IgorZ wrote:Source of the post Точно то же самое будет относиться и к алиасу - его тоже надо будет сокращать.
Человек в начале темы просил. Именно для компактного представления. А мне всё равно, обратите внимание это поле не поддерживается сейчас.
Да мне тоже, в общем-то, если бы не один момент: которое из них считать приоритетным при выводе, если заполнены оба?
John Doe wrote:
IgorZ wrote:Source of the post Зачем применять громоздкое решение там, где можно обойтись простым и лёгким?
Простое и лёгкое тоже надо реализовывать, отлаживать, спустя время обнаруживать ошибки, и отлаживать снова.
Или взять готовый модуль на 10 килобайт.
Я набросал три строчки для перевода строки в таблицу. Там практически негде допускать ошибку. Подозреваю, если использовать regex, будет ещё короче (могу накидать, если надо). Единственное - по сравнению с модулем более строгий формат строки. Но лично я считаю это достоинством.
Впрочем, охота использовать сторонний модуль - хозяин барин. Я высказываю аргументированное мнение, а не отдаю приказы.
John Doe wrote:
IgorZ wrote:Source of the post Но предполагаю, что их наличие упростит работу браузера.
Вот и я предполагаю.
Но реально в MacroBrowserAlt в ближайшее время внедрять не буду (его ещё доделать надо), поэтому пишите если что реально понадобится.
Позже, наверное, точно скажу. Сейчас у меня пока только ощущение, что оно понадобится.
John Doe wrote:
IgorZ wrote:Source of the post Предпочитаю сделать сразу, а не добавлять потом.
Это если бы наверняка знать что делать)
Просто хотелось бы иметь возможность по, допустим, F3, просмотреть список всех файлов, входящих в пакет, с указанием типа содержимого и/или описания. И чтоб список этот не приходилось составлять самому из кучи источников. И существенная часть моих замечаний относится как раз к тому, чтоб реализовать это в regscript наиболее удобным и наименее затратным способом.
John Doe wrote:
IgorZ wrote:Source of the post Плагины, как исторически сложилось, всегда лежат в отдельной папке. У скриптов всё гораздо сложнее. И не только с местоположением, но и с расширениями файлов.
А я вот не против. Используйте любые новые поля, если они нужны для каких-то задач.
IgorZ wrote:Source of the post И лучше тот интерфейс, который лучше поддерживает расширяемость. А таблица в этом смысле несоизмеримо лучше строки.
С таблицей тоже не будет сладко, и можно долго спорить что туда писать и в каком формате.
Поэтому пусть будет строка, в конце концов её очень легко заменить на таблицу когда это реально понадобится.
Если вообще понадобится, потому что пока всего предложенного можно достичь штатным путём.
То есть, скажем, вместо лоббирования изменения типа поля files на таблицу, ввести поле tfiles? Можно, конечно, но не очень красиво, на мой взгляд. Может тогда, хотя бы временно, разрешить для этого поля и стороковый, и табличный тип? Для версии, как я понял, это так и будет.
John Doe wrote:
IgorZ wrote:Source of the post Несколько nfo в файле смотрятся и понимаются хуже, чем аккуратно оформленная вложенная таблица в единственном nfo.
А по-моему нечего там особо смотреть.
Постарался сделать всё так, чтобы не множить сущности.
И вроде бы удалось сохранить баланс между простотой и универсальностью.
Думаю, тут нужен крупный пакет из кучи файлов. Оформить nfo тем и другим способом. И можно будет говорить уже более предметно. А сейчас мы просто перетягиваем канат, образно говоря.

IgorZ
Posts: 436
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Postby IgorZ » Mon 15 Aug, 2016 10:11

John Doe wrote:
IgorZ wrote:Source of the post Можно также извратиться и задавать имя функции строкой, а возможные параметры ещё одной строкой: help = [[ShowHelp]], [["main"]].Так-то идея правильная. Надо только ShiftF1 и F9 задать, как для плагинов.
Хоткеи сделаю, а имя+параметры никак не получится, да и не надо, ведь можно просто обернуть всё в функцию.

Другой вопрос. Подозреваю во многих случаях в качестве help достаточно строки.
И вот тут возможны варианты: то ли допускать в это поле и строку и функцию, то ли для строкового представления завести отдельное поле, например helptxt.
Преимуществом первого варианта я считаю невозможность одновременного существования обоих сущностей.
Но может это и ничего.
Мнения?
Насчёт обёртки в функцию - да, тоже вариант. Так что, по сути, проблемы нет.
Если речь идёт о справке, встроенной в скрипт, там текстовое поле возможно только в самом примитивном случае, когда вся справка - один кусок текста, не зависящий ни от чего. Если появляется зависимость от языка - уже могут возникнуть проблемы, а если справка контекстно-записимая или вообще на основе справки Far, то тут уже точно строкой никак не обойтись. Так что наиболее правильным вариантом считаю допускать и строку, и функцию. Для MenuItem работает, и тут сгодится. А отдельное поле приведёт к тому, что рано или поздно кто-то заполнит и то, и другое. И зачем провоцировать людей?

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

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

Postby John Doe » Mon 15 Aug, 2016 10:29

IgorZ wrote:Source of the post Да мне тоже, в общем-то, если бы не один момент: которое из них считать приоритетным при выводе, если заполнены оба?
Имя, если укладывается в заданную ширину.
IgorZ wrote:Source of the post И чтоб список этот не приходилось составлять самому из кучи источников.
О работе с пакетом как с единым целым предстоит ещё подумать. Пока мне не очень понятно, какие действия реально нужны, поэтому ни интерфейсом ни реализацией ещё не занимался.
IgorZ wrote:Source of the post То есть, скажем, вместо лоббирования изменения типа поля files на таблицу, ввести поле tfiles? Можно, конечно, но не очень красиво, на мой взгляд.
Пока всё в стадии эксперимента можно о красоте не беспокоиться. А потом выберем и оставим лучший вариант.
IgorZ wrote:Source of the post Для версии, как я понял, это так и будет.
В ближайшее время не собирался усложнять.
До контроля версий между компонентами пакета ещё очень и очень далеко.
SemVer тоже пока предлагаю только на уровне рекомендации, а фактически ничего ещё не парсится (хоть это и просто).
IgorZ wrote:Source of the post Я набросал три строчки для перевода строки в таблицу.
И ещё три для сравнения версий, и т.д.
Потом всё отладить и получится тот же semver.lua
Посмотрите, он очень маленький.
IgorZ wrote:Source of the post Думаю, тут нужен крупный пакет из кучи файлов.
Согласен, нужна практика.
Особо крупных пакетов ожидать не стоит.
А отдельное поле приведёт к тому, что рано или поздно кто-то заполнит и то, и другое.
Имхо это проблема даже проще, чем разобрать содержимое поля в зависимости от типа.
Так что не знаю даже..

P.S.
В следующей версии будет несколько изменён рекомендованный способ регистрации:

Code: Select all

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
(подробнее в шапке)

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

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

Postby John Doe » Mon 15 Aug, 2016 21:37

В шапке версия 0.1, описание приведено в соответствие с новыми возможностями
  • Изменён рекомендуемый способ регистрации
  • Реализовано хранение собственных настроек в таблице, для интерактивного изменения, и переопределения начальных значений без необходимости правки исходников.
    Прежде всего это позволяет в простых скриптах не беспокоиться о реализации пользовательских настроек.
    (собственно сейчас в этих случаях никто и не беспокоится, подобные "настройки" просто представлены константами в исходнике)
  • scriptbrowser: добавлены столбцы с версиями и со статусами
    <‼☼?oс (скрипт второго уровня,ошибка,функции настройки и справки,опции,переопределение)
  • Для пробы поддержано поле helptxt

IgorZ
Posts: 436
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Postby IgorZ » Tue 16 Aug, 2016 07:30

John Doe wrote:
IgorZ wrote:Source of the post И чтоб список этот не приходилось составлять самому из кучи источников.
О работе с пакетом как с единым целым предстоит ещё подумать. Пока мне не очень понятно, какие действия реально нужны, поэтому ни интерфейсом ни реализацией ещё не занимался.
А зря - это же IMHO самое вкусное. Действия - просмотр всего пакета, переход между файлами и пакетом. Как разработчик не отказался бы от копирования всего пакета на пассивную или временную панель, да и других (возможно, назначаемых?) действий. Пакет получается отдельной сущностью, а не описанием головного файла пакета.
Кстати, на подумать: не предусмотреть ли возможность действительно выносить описалово в отдельный .nfo файл?
Тут же допишу, чтоб все мысли в куче: история версий - может, её тоже не помешало бы каким-то образом формализовать и включить в nfo? Как вариант, в качестве отдельного файла?
John Doe wrote:
IgorZ wrote:Source of the post То есть, скажем, вместо лоббирования изменения типа поля files на таблицу, ввести поле tfiles? Можно, конечно, но не очень красиво, на мой взгляд.
Пока всё в стадии эксперимента можно о красоте не беспокоиться. А потом выберем и оставим лучший вариант.
Ладно, попробую. Тогда (предварительно) будет просмотр tfiles, если его нет, то files.
John Doe wrote:
IgorZ wrote:Source of the post Думаю, тут нужен крупный пакет из кучи файлов.
Согласен, нужна практика.
Особо крупных пакетов ожидать не стоит.
Я свои подключу, Вы своё, может, ещё кто заинтересуется. SimSU бы заинтересовать - это был бы прорыв! Количественный, как минимум.
John Doe wrote:
А отдельное поле приведёт к тому, что рано или поздно кто-то заполнит и то, и другое.
Имхо это проблема даже проще, чем разобрать содержимое поля в зависимости от типа.
Так что не знаю даже..
Ладно. Я так понял, helptxt будет сразу показываться, а help вызываться? Тогда получаем фактически уже 4 сходных по смыслу поля: alias, name, description, helptxt (по нарастанию длины текста).

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

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

Postby John Doe » Tue 16 Aug, 2016 08:06

IgorZ wrote:Source of the post Действия - просмотр всего пакета, переход между файлами и пакетом.
Это ж есть изначально, хоть вероятно реализовано и не совсем так как вы имеете ввиду.
IgorZ wrote:Source of the post Как разработчик не отказался бы от копирования всего пакета
Об этом думал. Ещё: отключение [макросов] всего пакета.
Пока кажется что для большинства вариантов применения достаточно завести в апи функцию, позволяющую получить общий неструктурированый список файлов.
IgorZ wrote:Source of the post не предусмотреть ли возможность действительно выносить описалово в отдельный .nfo файл?
Выделить для этого отдельный файл можно и сейчас. Т.е. завести какой-нибудь package_meta.lua с описанием пакета, а остальные скрипты будут ссылаться на него в parent_id.
Но вы вероятно имели ввиду другое: собрать всю метаинформацию в один файл, а сами скрипты будут от неё свободны. Нет, мне не кажется это хорошей мыслью.
А вот генерировать сводный отчёт о пакете может быть полезно, да.
IgorZ wrote:Source of the post Тогда получаем фактически уже 4 сходных по смыслу поля: alias, name, description, helptxt
Верно.
Но: alias пока не поддерживается. А насчёт helptxt пока думаю, возможно не нужна никакая специальная поддержка.
Вместо этого другая мысль: отображать в информации все поля, а не только "поддерживаемые". (вопрос в том, отображать ли полностью, как сейчас helptxt, или же по нажатию отображать развёрнуто, в диалоге)
IgorZ wrote:Source of the post история версий - может, её тоже не помешало бы каким-то образом формализовать и включить в nfo?
Включить легко, хоть сейчас.
Если в виде отдельного поля, то см. замечание насчёт helptxt. Аналогичным образом можно любую информацию добавить, например лицензию.
Если отдельным файлом, то опять же, хоть сейчас в поле files. Оттуда легко открыть файл.
В следующей версии это можно будет сделать и из общего списка скриптов.

P.S.
Что касается типа содержимого.
Предлагаю не вводить новые сущности, а приравнять тип к расширению (или определять по маске).

IgorZ
Posts: 436
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Postby IgorZ » Wed 17 Aug, 2016 07:17

John Doe wrote:
IgorZ wrote:Source of the post Действия - просмотр всего пакета, переход между файлами и пакетом.
Это ж есть изначально, хоть вероятно реализовано и не совсем так как вы имеете ввиду.
IgorZ wrote:Source of the post Как разработчик не отказался бы от копирования всего пакета
Об этом думал. Ещё: отключение [макросов] всего пакета.
Пока кажется что для большинства вариантов применения достаточно завести в апи функцию, позволяющую получить общий неструктурированый список файлов.
Скажем так: я предлагаю больше использовать идеологию ООП. В приложении к Луа это значит, что у нас есть одна таблица (возможно, сложной структуры), описывающая весь пакет. Если список входящих файлов будет выдаваться функцией-полем этой таблицы, почему бы и нет?
John Doe wrote:
IgorZ wrote:Source of the post не предусмотреть ли возможность действительно выносить описалово в отдельный .nfo файл?
Выделить для этого отдельный файл можно и сейчас. Т.е. завести какой-нибудь package_meta.lua с описанием пакета, а остальные скрипты будут ссылаться на него в parent_id.
Но вы вероятно имели ввиду другое: собрать всю метаинформацию в один файл, а сами скрипты будут от неё свободны. Нет, мне не кажется это хорошей мыслью.
А вот генерировать сводный отчёт о пакете может быть полезно, да.
В обязательном порядке - нет, не предлагаю. Но наряду с *.lua сканировать *.nfo, предполагая внутри наличие nfo - вот над этим подумать.
John Doe wrote:
IgorZ wrote:Source of the post Тогда получаем фактически уже 4 сходных по смыслу поля: alias, name, description, helptxt
Верно.
Но: alias пока не поддерживается. А насчёт helptxt пока думаю, возможно не нужна никакая специальная поддержка.
Вместо этого другая мысль: отображать в информации все поля, а не только "поддерживаемые". (вопрос в том, отображать ли полностью, как сейчас helptxt, или же по нажатию отображать развёрнуто, в диалоге)
Второй вариант, разумеется, а то наплодит кто-нибудь 100500 полей, и выводи их. LuaExplorer для этого, думаю, идеально подходит. Если же его нет, просто выводить список названий пользовательских полей.
John Doe wrote:
IgorZ wrote:Source of the post история версий - может, её тоже не помешало бы каким-то образом формализовать и включить в nfo?
Включить легко, хоть сейчас.
Если в виде отдельного поля, то см. замечание насчёт helptxt. Аналогичным образом можно любую информацию добавить, например лицензию.
Если отдельным файлом, то опять же, хоть сейчас в поле files. Оттуда легко открыть файл.
В следующей версии это можно будет сделать и из общего списка скриптов.
Может, и так. Но я прикидывал насчёт некоторой формализации структуры истории и, соответственно, расширенных возможностей вывода. Может, и лишку, конечно.
John Doe wrote:Что касается типа содержимого.
Предлагаю не вводить новые сущности, а приравнять тип к расширению (или определять по маске).
Невозможно практически. Навскидку: файл с настройками может быть .lua, .cfg, .ini, без расширения, .lua_cfg, .lua.cfg... У кого на что фантазии хватит - обязательной стандартизации-то нет. С языковыми почти та же история, усугубляемая тем, что там ещё запросто могут всплыть расширения, включающие "rus", "eng" и другие языковые сокращения. В общем, отдельное поле в данном случае и проще, и надёжнее. А бояться, что автор поленится заполнить поле - так он и вообще всё nfo ещё скорее поленится заполнять.

P. S. Имеет ли смысл вводить поле - адрес данных скрипта в БД LuaMacro? Просто, если оно есть, то имеет смысл сделать переход по ссылке - скажем, с помощью DBEdit. Он, правда, пока не вызывается как модуль, но это нетрудно добавить.

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

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

Postby John Doe » Wed 17 Aug, 2016 07:54

IgorZ wrote:Source of the post В приложении к Луа это значит, что у нас есть одна таблица (возможно, сложной структуры), описывающая весь пакет.
Я не знаю нужна ли такая сводная таблица на практике, но если да, то она может быть построена программно, а исходные таблицы при этом стоит оставить максимально простыми.
IgorZ wrote:Source of the post Но наряду с *.lua сканировать *.nfo, предполагая внутри наличие nfo - вот над этим подумать.
Рекурсивно обходя содержимое scripts?
IgorZ wrote:Source of the post Второй вариант, разумеется, а то наплодит кто-нибудь 100500 полей, и выводи их.
И выведу)
Пока реализовал так: если количество строк меньше заданного, то выводится полный текст, иначе только первая строка.
IgorZ wrote:Source of the post Но я прикидывал насчёт некоторой формализации структуры истории
В дальней перспективе, когда мы с вами реализуем автообновление скриптов, это может быть полезно.
IgorZ wrote:Source of the post У кого на что фантазии хватит - обязательной стандартизации-то нет.
Если нужна, то почему нет. Запросто.
IgorZ wrote:Source of the post А бояться, что автор поленится заполнить поле - так он и вообще всё nfo ещё скорее поленится заполнять.
Автор сразу правильно назовёт файл, и это избавит и его и нас от лишней работы.
IgorZ wrote:Source of the post Имеет ли смысл вводить поле - адрес данных скрипта в БД LuaMacro?
Хорошая мысль.
Поле можно назвать dbkey.
А как будем передавать адрес? строкой? таблицей?

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

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

Postby John Doe » Wed 17 Aug, 2016 07:59

Хотелось бы также получить отзывы по способу регистрации скрипта (помимо структуры таблицы).

И отзывы/пожелания по работе с настройками.
Пока в планах добавить возможность автосохранения отдельных (указанных) опций в базе, и справку по самим опциям.
(Речь о произвольных собственных опциях скриптов, тех что задаются в поле options.)

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

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

Postby John Doe » Thu 18 Aug, 2016 20:12

IgorZ wrote:Source of the post Насчёт "слишком рано": local имя_будущей_функции не принесёт особого вреда. Хоть и будет смотреться в ряде случаев не очень красиво.
Сейчас этого можно избежать, добавляя функцию в таблицу позже.
Ведь скрипт после регистрации "владеет" своей таблицей, и можно сделать просто так:

Code: Select all

nfo.config = function(...)
  --
end

IgorZ wrote:Source of the post Так что наиболее правильным вариантом считаю допускать и строку, и функцию.
В следующей версии в функцию при вызове будут передаваться параметры nfo и name.
Таким образом можно будет делать и так:

Code: Select all

local nfo = Info {
  --...
  helptxt = [[long help message]];
 
  help = function(nfo,name)
    far.Message(nfo.helptxt)
  end;
}

IgorZ
Posts: 436
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Postby IgorZ » Fri 19 Aug, 2016 07:05

John Doe wrote:она может быть построена программно
Собственно, пока суть да дело, я уже так и сделал.
John Doe wrote:
IgorZ wrote:Source of the post Но наряду с *.lua сканировать *.nfo, предполагая внутри наличие nfo - вот над этим подумать.
Рекурсивно обходя содержимое scripts?
Другого способа не вижу. Так что или так, или никак.
John Doe wrote:
IgorZ wrote:Source of the post Но я прикидывал насчёт некоторой формализации структуры истории
В дальней перспективе, когда мы с вами реализуем автообновление скриптов, это может быть полезно.
Тогда пока отложить на будущее?
John Doe wrote:
IgorZ wrote:Source of the post У кого на что фантазии хватит - обязательной стандартизации-то нет.
Если нужна, то почему нет. Запросто.
И как заставить всех абсолютно авторов? Добавить код, рекурсивно обходящий папку Macros и удаляющий все файлы с "некошерными" расширениями? Ибо альтернативой - только добрая воля (субстанция куда более редкая, чем хотелось бы).
John Doe wrote:
IgorZ wrote:Source of the post А бояться, что автор поленится заполнить поле - так он и вообще всё nfo ещё скорее поленится заполнять.
Автор сразу правильно назовёт файл, и это избавит и его и нас от лишней работы.
А какое расширение - правильное? Скажем, если у файла типичная .ini структура, то и расширение напрашивается аналогичное. А если внутри Луа-код, то и расширение логично поставить .lua. Но при этом для соответствующего скрипта и то, и другое - файл настроек. Говоря научно, тип файла - следующий, более высокий уровень абстракции (описывающий назначение содержимого файла) в сравнении с его расширением (описывающим структуру внутреннего содержимого), и именно он нас и интересует.
И ещё одно соображение. Если, к примеру и языковые настройки, и справка находятся в одном файле (у самого в некоторых скриптах так), то отдельное поле типа позволит явно это указать, а ориентирование по расширению окажется бесполезно.
John Doe wrote:
IgorZ wrote:Source of the post Имеет ли смысл вводить поле - адрес данных скрипта в БД LuaMacro?
Хорошая мысль.
Поле можно назвать dbkey.
А как будем передавать адрес? строкой? таблицей?
Строкой. В DBEdit есть парсер, так что надобности в более сложном варианте нет. Строка должна быть такой:
"[LOCAL|GLOBAL](по умолчанию GLOBAL)[<разделитель><элемент пути>]..." Разделителем сейчас \n (максимально радикально), так что это обсуждаемо, но крайне желателен символ, невозможный в имени переменной.

IgorZ
Posts: 436
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Postby IgorZ » Fri 19 Aug, 2016 07:26

John Doe wrote:Хотелось бы также получить отзывы по способу регистрации скрипта (помимо структуры таблицы).
Я что-то крупное не заметил? Реализован ещё какой-то способ регистрации, кроме nfo-таблиц? Или речь о предлагаемых на будущее вариантах? Что-то в упор не помню, чтоб это обсуждалось.
John Doe wrote:И отзывы/пожелания по работе с настройками.
Пока в планах добавить возможность автосохранения отдельных (указанных) опций в базе, и справку по самим опциям.
(Речь о произвольных собственных опциях скриптов, тех что задаются в поле options.)
Пока вплотную этим не успел заняться, поэтому ничего особо не скажу, вроде всё по уму. Единственно: хотелось бы видеть это независимым от regscript механизмом. Это возможно?

IgorZ
Posts: 436
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Postby IgorZ » Fri 19 Aug, 2016 07:33

John Doe wrote:Ведь скрипт после регистрации "владеет" своей таблицей, и можно сделать просто так:

Code: Select all

nfo.config = function(...)
  --
end
Хм. И точно...
John Doe wrote:
IgorZ wrote:Source of the post Так что наиболее правильным вариантом считаю допускать и строку, и функцию.
В следующей версии в функцию при вызове будут передаваться параметры nfo и name.
Таким образом можно будет делать и так:

Code: Select all

local nfo = Info {
  --...
  helptxt = [[long help message]];
 
  help = function(nfo,name)
    far.Message(nfo.helptxt)
  end;
}
Можно и так. Хотя, в принципе, любой вариант вполне рабочий.

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

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

Postby John Doe » Fri 19 Aug, 2016 07:42

IgorZ wrote:Source of the post Тогда пока отложить на будущее?
Обсудить может быть полезно и сейчас.
IgorZ wrote:Source of the post И как заставить всех абсолютно авторов? Добавить код, рекурсивно обходящий папку Macros и удаляющий все файлы с "некошерными" расширениями? Ибо альтернативой - только добрая воля (субстанция куда более редкая, чем хотелось бы).
Не будем заставлять)
Если автор позаботился о регистрации скрипта, значит увидел для себя какую-то в этом пользу, и (будем надеяться) предварительно изучил прилагающуюся документацию.
IgorZ wrote:Source of the post А если внутри Луа-код, то и расширение логично поставить .lua. Но при этом для соответствующего скрипта и то, и другое - файл настроек.
Файлы с расширением lua в папке scripts это скрипты. Они могут себя зарегистрировать сами, в частности используя и специальное поле для типа.
Аналогично, они могут быть зарегистрированы и из основного скрипта дополнительным вызовом Info.
И третий вариант, тип "настройки" например может быть определён и маской вида *.cfg.*
(В следующей версии я уже ввёл типы, пока только в browser)

IgorZ wrote:Source of the post Если, к примеру и языковые настройки, и справка находятся в одном файле (у самого в некоторых скриптах так), то отдельное поле типа позволит явно это указать, а ориентирование по расширению окажется бесполезно.
Используя Info вы можете предусмотреть и такую гипотетическую ситуацию, если это необходимо.

IgorZ wrote:Source of the post крайне желателен символ, невозможный в имени переменной.
Знаю только один такой \0.
Ну а на практике вряд ли есть необходимость использовать даже слэш.
С другой стороны, использование таблицы позволило бы не делать никаких допущений о практике.

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

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

Postby John Doe » Fri 19 Aug, 2016 08:50

IgorZ wrote:Source of the post Я что-то крупное не заметил? Реализован ещё какой-то способ регистрации, кроме nfo-таблиц?
Я имел ввиду всю обвязку, в том числе получение функции Info (и само её название), завершающее условие (оно добавляет громоздкости), манипуляции с опциями.
IgorZ wrote:Source of the post хотелось бы видеть это независимым от regscript механизмом. Это возможно?
Возможно всё, но есть ли смысл?
В простейшем случае это сейчас так:

Code: Select all

local Info = package.loaded.regscript or function(...) return ... end
local nfo = Info { ...,
  id = "EE765F8C-EF4B-4820-A3E5-DFD25F280852";
  options = {
    --...
  };
}
if not nfo then return end
local O = nfo.options
Собственно, мне лично тоже не нравится как сейчас опции загромождают определение.

Можно было бы сделать независимо, например как-то так:

Code: Select all

local options = {
    --...
  };
local cfg = package.loaded.cfgscript or function(...) return ... end
if not cfg(options,"EE765F8C-EF4B-4820-A3E5-DFD25F280852") then return end
Условие тут обязательно, это единственный способ "отключения" скрипта...

Ещё можно объединить варианты, как-то так:

Code: Select all

local nfo = Info { ...,
  id = "EE765F8C-EF4B-4820-A3E5-DFD25F280852";
  --...
}
if not nfo then return end

local O = {
    --...
  };
nfo:cfg(O)
Таблицу опций и в этом случае может сохраняться в nfo, для удобства доступа браузера.
Но можно и отдельную функцию.

В общем, нужна обратная связь.

P.S.
IgorZ wrote:Source of the post Можно и так.
А вызывать тогда в духе ооп: nfo:help()


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

Who is online

Users browsing this forum: No registered users and 1 guest