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

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

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

Post by John Doe » Tue 09 Aug, 2016 16:10

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

Но раз каждый скрипт в любом случае содержит какую-то метаинформацию, то почему бы не заполнять её стандартизировано?
В результате мы получим возможность управлять скриптами централизованно, и реализовать разные интересные возможности, такие как изложенные ранее: viewtopic.php?p=121966#p121966

Представляю экспериментальную реализацию некоторых идей:
Основные понятия:
  • Скрипт — это 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 62 times

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

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

Post by John Doe » Tue 25 Oct, 2016 13:18

Latest post of the previous page:

IgorZ wrote: Вот. Адрес можно задавать и таблицей, и строкой.
В спецификации пакета достаточно будет строки, имхо.

Но есть другой вопрос: как лучше поступить с LOCAL/GLOBAL?
В моей практике настройки лежат либо только в GLOBAL, либо в обоих базах (в ключе с тем же путём).

Если же делать совсем универсально, то надо указывать полный перечень ключей, с указанием LOCAL/GLOBAL, и этих ключей может быть не 2, а сколько угодно.
Как по мне, то это будет перебор.

Проще всего LOCAL/GLOBAL в спецификации не указывать, что я и предлагаю.

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

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

Post by IgorZ » Wed 26 Oct, 2016 09:15

John Doe wrote:
IgorZ wrote: Вот. Адрес можно задавать и таблицей, и строкой.
В спецификации пакета достаточно будет строки, имхо.
Ну не выкидывать же теперь возможность! ;) Вы, коллега, сами же преложили в виде таблицы задавать, а теперь на попятную? :) :) :)
John Doe wrote:Но есть другой вопрос: как лучше поступить с LOCAL/GLOBAL?

Проще всего LOCAL/GLOBAL в спецификации не указывать, что я и предлагаю.
Неясно, как тогда действовать? Ладно, если данные только в одной базе, можно проверять обе и показывать ту, что есть, а если в обеих? Разве что предусмотреть клавишу "перейти на этот ключ в другой базе"? Кстати, неплохая идея независимо от всего.
Кстати, BookmarkManager хранит данные аж в трёх местах: локальные закладки, глобальные закладки и настройки. И как тут быть? Явно, надо предусмотреть возможность указывать несколько ключей. Как вариант, можно условиться, что несколько адресов задаются таблицей, а один можно и не таблицей с одним элементом, а просто строкой. Самую малость сложнее в обработке, но в тривиальных случаях упрощает заполнение nfo.
Да, для таблицы адреса можно задавать в виде описание=адрес. Думаю, будет наглядно и удобно.

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

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

Post by John Doe » Wed 26 Oct, 2016 09:41

IgorZ wrote: Ну не выкидывать же теперь возможность! ;)
Из dbedit да, конечно не выкидывать.
Но это не значит, что обязательно надо сразу применять именно тут.
IgorZ wrote: Разве что предусмотреть клавишу "перейти на этот ключ в другой базе"?
Именно
IgorZ wrote: Кстати, BookmarkManager хранит данные аж в трёх местах: локальные закладки, глобальные закладки и настройки. И как тут быть?
Зависит от целей.
Если рассматривать эту функцию как возможность менять параметры для простых скриптов, избавляющую их от реализации в каждом случае собственного интерфейса, то для BookmarkManager это вообще не очень актуально.

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

И раз уж мы о BookmarkManager, то не могли бы вы на его примере проиллюстрировать ваши предложения.

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

Менеджер закладок для папок

Post by John Doe » Wed 26 Oct, 2016 11:38

IgorZ wrote: Nfo
В макросах используется поле uid

Функция описания определена не тем способом, что рекомендован в актуальной версии ScriptsBrowser:

Code: Select all

local Info = Info or package.loaded.regscript or function(...) return ... end --luacheck: ignore 113/Info
Напомню, что идея в том, чтобы браузер мог получить описание (например из дистрибутива), передав в окружение собственную функцию Info.

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

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

Post by IgorZ » Wed 26 Oct, 2016 11:47

John Doe wrote:И раз уж мы о BookmarkManager, то не могли бы вы на его примере проиллюстрировать ваши предложения.
  1. --...
  2.   dbkey = {
  3.     "Локальные закладки" = "LOCAL//IgorZ//BookmarkManagerData";
  4.     "Общие закладки" = "GLOBAL//IgorZ//BookmarkManagerData";
  5.     "Настройки скрипта" = "GLOBAL//IgorZ//BookmarkManagerConfig"
  6.   };
  7. --...
Примерно так. А для, к примеру, LuaManager
  1. --...
  2.   dbkey = "IgorZ//LuaManager";
  3. --...
что внутри буквально одной строкой превратится в (разумеется, я о результате)
  1. --...
  2.   dbkey = { "Настройки скрипта" = "IgorZ//LuaManager"; };
  3. --...

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

Менеджер закладок для папок

Post by IgorZ » Wed 26 Oct, 2016 11:58

John Doe wrote:В макросах используется поле uid
Это о чём???

P. S. А, понял! Да, косяк...
John Doe wrote:Функция описания определена не тем способом, что рекомендован в актуальной версии ScriptsBrowser:

Code: Select all

local Info = Info or package.loaded.regscript or function(...) return ... end --luacheck: ignore 113/Info
Напомню, что идея в том, чтобы браузер мог получить описание (например из дистрибутива), передав в окружение собственную функцию Info.
*ворчливо* Как в шапке ScriptBrowser написано, так и пишу.

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

Менеджер закладок для папок

Post by John Doe » Wed 26 Oct, 2016 12:05

IgorZ wrote: P. S. А, понял! Да, косяк...
С dbedit то же самое
IgorZ wrote: Как в шапке ScriptBrowser написано, так и пишу.
А это мой косяк. В шаблоне изменил, а в шапке нет.

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

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

Post by John Doe » Mon 31 Oct, 2016 13:25

В DBEdit (как впрочем и в других скриптах) заметил использование поля helptxt, которое показалось мне спорным.
Туда попала довольно специфическая информация, вряд ли интересная именно в Scripts Browser, учитывая что по ShiftF1 открывается полноценная справка (hlf).

Т.е. в данном случае это поле либо не стоит применять вообще, либо разместить там общее описание (то что в справке называется "О скрипте").

Также, предлагаю ещё раз взглянуть на поле history.По текущему содержанию вроде бы вопросов нет.
Но ведь лог изменений имеет свойство расти. Стоит ли пихать всё в nfo? (Помимо прочего это ещё и бессмысленный расход памяти).
Лично я бы предпочёл историю отдельным файлом, ссылка на который будет присутствовать в поле files.

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

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

Post by IgorZ » Tue 01 Nov, 2016 07:49

John Doe wrote:В DBEdit (как впрочем и в других скриптах) заметил использование поля helptxt, которое показалось мне спорным.
Туда попала довольно специфическая информация, вряд ли интересная именно в Scripts Browser, учитывая что по ShiftF1 открывается полноценная справка (hlf).

Т.е. в данном случае это поле либо не стоит применять вообще, либо разместить там общее описание (то что в справке называется "О скрипте").
Я планировал разместить в этом поле короткую информацию об использовании скрипта на тот гипотетический случай, если файлы справки будут отсутствовать. Но, судя по замечанию, перестарался.
John Doe wrote:Также, предлагаю ещё раз взглянуть на поле history.По текущему содержанию вроде бы вопросов нет.
Но ведь лог изменений имеет свойство расти. Стоит ли пихать всё в nfo? (Помимо прочего это ещё и бессмысленный расход памяти).
Лично я бы предпочёл историю отдельным файлом, ссылка на который будет присутствовать в поле files.
Есть определённые сложности. На файл с историей нет ни писанных, ни исторически сложившихся чётких стандартов имени и расширения. Какие только варианты не встречаются: и changelog, и whatsnew, и history; без расширения, .txt, .язык_истории, .hst,.new... Как разбираться с таким зоопарком - не знаю. Наиболее логичным представляется или вводить отдельное поле для файла истории, или добавить в поле files возможность указывать типы файлов, как я предлагал раньше. Можно было бы, конечно, проигнорировать определение данного типа файла (положившись на то, что пользователь сам догадается, что это, а стандартный просмотр, независимый от типа файла, есть), но мы когда-то говорили о разборе истории в программе и использовании её, в частности, при установке пакетов. Если эти планы ещё живы, правильно было бы реализовывать их поддержку сразу по мере введения соответствующих сущностей.

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

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

Post by John Doe » Tue 01 Nov, 2016 12:29

IgorZ wrote: мы когда-то говорили о разборе истории в программе и использовании её, в частности, при установке пакетов.
Для файлов со стандартизированной структурой определённо понадобится отдельное поле.
Все прочие будучи перечислены в files уже сейчас вроде бы успешно определяются по маске, весь зоопарк.
IgorZ wrote: Если эти планы ещё живы, правильно было бы реализовывать их поддержку сразу по мере введения соответствующих сущностей.
Планы в планах.
Сущности вводить считаю пока преждевременным.

Post Reply

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