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

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

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

Post by John Doe »

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

Но раз каждый скрипт в любом случае содержит какую-то метаинформацию, то почему бы не заполнять её стандартизировано?
В результате мы получим возможность управлять скриптами централизованно, и реализовать разные интересные возможности, такие как изложенные ранее: http://forum.farmanager.com/viewtopic.p ... 66#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 295 times
User avatar
HaRT
Moderator
Posts: 10806
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 220 times
Been thanked: 357 times

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

Post by HaRT »

John Doe, поясните, пжлст, про parent/subscripts.
Кстати, слово subscript имеет устоявшееся другое значение, т.ч. предлагаю хотя бы через дефис: “sub-scripts”.
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
John Doe
Бюрократ
Posts: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

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

Post by John Doe »

HaRT wrote: parent/subscripts.
Скрипты можно организовывать иерархически.
Если есть несколько скриптов с одним parent_id, то для родительского скрипта они будут под-скриптами.
Shmuel
Posts: 6815
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 41 times
Been thanked: 526 times

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

Post by Shmuel »

Code: Select all

╔════════════════════════════════════ LuaMacro ═════════════════════════════════════╗
║ ...ta\Far Manager\Profile\Macros\scripts\scriptsbrowser.lua:1: regscript required ║
╟───────────────────────────────────────────────────────────────────────────────────╢
║                                  { OK } [ Edit ]                                  ║
╚═══════════════════════════════════════════════════════════════════════════════════╝
User avatar
John Doe
Бюрократ
Posts: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

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

Post by John Doe »

Shmuel
John Doe wrote: regscript.lua — сам модуль, регистрирующий скрипты.
Должен быть подключен в _macroinit.lua: require"regscript"
Shmuel
Posts: 6815
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 41 times
Been thanked: 526 times

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

Post by Shmuel »

Да, спасибо, уже и сам разобрался. Устал сегодня.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

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

Post by IgorZ »

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, или что-то другое?
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

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

Post by Smitis »

IgorZ wrote:таблица relations с указанием сторонних пакетов, которые обязательно или опицонально требуются для работы данного пакета.
Имхо, лучше название dependencies
Разум когда-нибудь победит.
User avatar
John Doe
Бюрократ
Posts: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

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

Post by John Doe »

IgorZ wrote: Поле name: свободное значение, как я смотрю? Тогда чем оно отличается от description?
Тем же чем имя плагина отличается от его описания. F11, F3
Имя короткое, Описание подлиннее.
Где-то просили ещё alias, как сокращённое имя. Например так
IgorZ wrote: Предлагаю ввести поле type, содержащее тип файла
А как это предлагается применять?
Наличие макросов выясняется на раз.
А что с остальным делать?
Если просто посмотреть, то в описание можно.
Если для какого-то анализа, то для какого именно?
IgorZ wrote: Также предлагаю ввести поле lang (ru,en...) для файлов с данными локализации.
Тот же вопрос. Что делать с этим полем?
(Локализовать саму метаинформацию да, смысл есть, и в todo записано)
IgorZ wrote: Для вспомогательных файлов пакета, возможно, имеет смысл ввести поле minpackageversion для контроля версий внутри пакета.
Смысл есть, типа parent_minversion. Но для практического применения необходимо стандартизировать способ указания версии. Как вам https://github.com/kikito/semver.lua ?
IgorZ wrote: Чуть не забыл: таблица relations с указанием сторонних пакетов, которые обязательно или опицонально требуются для работы данного пакета. К примеру, для LuaManager это могло бы выглядеть так:
И здесь у меня к вам тот же вопрос: зачем?
Автор должен иметь от этого прямую выгоду, иначе он просто не будет заполнять все эти поля. И будет прав.
IgorZ wrote: Не совсем понятны поля config и help. Это функции, выводящие справку и конфигурацию самих скриптов, имеющуюся независимо от regscript, или что-то другое?
Да, именно независимо.
(Про конфигурацию вы верно заметили, в следующей версии её будет предоставлять regscript).
P.S.
Хотя сейчас мне это уже не кажется особенно удобным: метаинформация у нас содержится в начале скрипта, а значит функцию придётся определять слишком рано.
User avatar
John Doe
Бюрократ
Posts: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

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

Post by John Doe »

IgorZ wrote: например [".\?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: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

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

Post by John Doe »

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

    Пока что мне видится так, что оба скрипта будут иметь отдельный интерфейс.
    Или (для удобства) же всё можно объединить в один интерфейс.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

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

Post by IgorZ »

Smitis wrote:
IgorZ wrote:таблица relations с указанием сторонних пакетов, которые обязательно или опицонально требуются для работы данного пакета.
Имхо, лучше название dependencies
Можно и так. Наверное, даже лучше, точнее передаёт смысл.
User avatar
John Doe
Бюрократ
Posts: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

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

Post by John Doe »

Обращаю внимание, что в настоящий момент считываются и запоминаются любые поля.
Т.о. со своими идеями можно экспериментировать не отходя от кассы
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

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

Post by IgorZ »

John Doe wrote:
IgorZ wrote: Поле name: свободное значение, как я смотрю? Тогда чем оно отличается от description?
Тем же чем имя плагина отличается от его описания. F11, F3
Имя короткое, Описание подлиннее.
Где-то просили ещё alias, как сокращённое имя. Например так
Особого смысла не вижу, но ради однообразия с плагинами - возможно, имеет смысл. А вот алиасы представляются мне совсем уж излишней сущностью. Алиас команды имеет смысл для сокращения часто повторяющегося набираемого вручную текста. Имя пакета разве будет набираться вручную?
John Doe wrote:
IgorZ wrote: Предлагаю ввести поле type, содержащее тип файла
А как это предлагается применять?
Наличие макросов выясняется на раз.
А что с остальным делать?
Если просто посмотреть, то в описание можно.
Если для какого-то анализа, то для какого именно?
Например, для быстрой сортировки или фильтрации нужного типа файлов без дорогостоящей и не всегда возможной операции потрошения их содержимого. Причём, те же языковые файлы могут быть в самом разном формате и иметь разное расширение, но при этом одну и ту же суть. Тут, наверное, нужно уточнить: в первую очередь описание типа необходимо для предлагаемой таблицы files, а в информации о самом файле это не столь актуально, но тоже удобно.
John Doe wrote:
IgorZ wrote: Также предлагаю ввести поле lang (ru,en...) для файлов с данными локализации.
Тот же вопрос. Что делать с этим полем?
(Локализовать саму метаинформацию да, смысл есть, и в todo записано)
А это логичное продолжение идеи с типами файлов. Кстати, можно, наверное, обойтись без отдельного поля, а ввести уточняющие суффиксы, например: "lng:ru", "help:en". Или даже "lng:en:ru", если в одном файле собраны несколько языковых локализаций.
John Doe wrote:
IgorZ wrote: Для вспомогательных файлов пакета, возможно, имеет смысл ввести поле minpackageversion для контроля версий внутри пакета.
Смысл есть, типа parent_minversion. Но для практического применения необходимо стандартизировать способ указания версии. Как вам https://github.com/kikito/semver.lua ?
Посмотрел. Мне кажется, {версия, подверсия, правка, сборка[,статус(альфа,бета,релиз и т. п.)]} и привычней, и удобней в работе, и проще формализуется и верифицируется, и не требует сторонних модулей.
John Doe wrote:
IgorZ wrote: Чуть не забыл: таблица relations с указанием сторонних пакетов, которые обязательно или опицонально требуются для работы данного пакета. К примеру, для LuaManager это могло бы выглядеть так:
И здесь у меня к вам тот же вопрос: зачем?
Автор должен иметь от этого прямую выгоду, иначе он просто не будет заполнять все эти поля. И будет прав.
Автор (любой) вообще в большинстве случаев не имеет прямой выгоды от выпуска и поддержки скриптов или плагинов. Тем не менее, авторы выкладывают, осуществляют поддержку, оформляют аккуратно шапку темы... Так что не всё так однозначно.
Тем не менее, определённая выгода есть. Информацию о зависимости от других разработок автор всё равно вынужден публиковать, а пользователь искать. И стандартизация этой информации (то есть, не дополнительная писанина, а формализация имеющейся) облегчит жизнь им обоим.
John Doe wrote:
IgorZ wrote: Не совсем понятны поля config и help. Это функции, выводящие справку и конфигурацию самих скриптов, имеющуюся независимо от regscript, или что-то другое?
Да, именно независимо.
(Про конфигурацию вы верно заметили, в следующей версии её будет предоставлять regscript).
P.S.
Хотя сейчас мне это уже не кажется особенно удобным: метаинформация у нас содержится в начале скрипта, а значит функцию придётся определять слишком рано.
Насчёт "слишком рано": local имя_будущей_функции не принесёт особого вреда. Хоть и будет смотреться в ряде случаев не очень красиво. Можно также извратиться и задавать имя функции строкой, а возможные параметры ещё одной строкой: help = [[ShowHelp]], [["main"]].Так-то идея правильная. Надо только ShiftF1 и F9 задать, как для плагинов.
John Doe wrote:
IgorZ wrote: например [".\?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: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

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

Post by John Doe »

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

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