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

Здесь обсуждается всё, что касается макросов.
User avatar
John Doe
Бюрократ
Posts: 11394
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 17 times
Been thanked: 101 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 71 times

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

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

Post by IgorZ » Thu 11 Aug, 2016 11:13

Latest post of the previous page:

John Doe wrote: Хотелось бы ещё отдельно обсудить две вещи, и ваше мнение как с автора LuaManager особенно важно.
  • разделение функций между regscript и scriptbrowser
    Сначала вся иерархия (родителей и под-скриптов) строилась в regscript (и была доступна прямо из таблицы скрипта, как поля subscripts и parents).
    Сейчас я сознательно упростил regscript до минимума, вынеся всю "аналитику" в scriptbrowser.
Мне кажется, regscript должен сводить всю информацию из всех файлов в единую таблицу с формализованной структурой, выявлять ошибки в данных, дополнять таблицу дополнительными к содержащимся в nfo данными (пример - уже имеющееся FileName), и на этом всё. Браузер должен полагаться, что полученная информация корректна, в строгом соответствии с оговорённым форматом структурирована и, насколько возможно, полна. Остальное - его работа. Как пример получаемой информации - данные, получаемые с помощью mf.GetMacroCopy.
John Doe wrote:
  • Как лучше осуществить интеграцию с макробраузерами пока что мне не очень понятно
    Какая информация нужна макробраузерам?
    Должны ли они всё получать от regscript, или для части функций имеет смысл использовать scriptbrowser (чтобы максимально избавить макробраузеры от реализации собственных велосипедов)
    Пока что мне видится так, что оба скрипта будут иметь отдельный интерфейс.
    Или (для удобства) же всё можно объединить в один интерфейс.
То есть, использовать ли scriptbrowser в качестве дополнительного модуля, содержащего функции обработки данных, полученных от regscript? Если останется возможность использовать regscript самостоятельно - почему бы и нет? Тут я вижу некоторую аналогию с тройкой "сервер БД - сервер приложений - клиент".
А велосипед - понятие относительное. Если, скажем, я добавлю поддержку regscript непосредственно в LuaManager (я пока не определился окончательно, как лучше сделать), то использование scriptbrowser может оказаться как бы не бОльшим велосипедом, чем использование уже имеющегося в LuaManager функционала. Общий принцип мне представляется таким: внешние функции обработки данных могут быть полезны, функции, относящиеся к форматированию и вывод информации, как правило, должны быть свои.

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

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

Post by John Doe » Thu 11 Aug, 2016 11:43

IgorZ wrote: Как пример получаемой информации - данные, получаемые с помощью mf.GetMacroCopy.
Да, так сейчас и сделано.
IgorZ wrote: дополнять таблицу дополнительными к содержащимся в nfo данными (пример - уже имеющееся FileName)
Вопрос до какой степени дополнять. Например, наличие под-скриптов, а может и их список.
IgorZ wrote: функции, относящиеся к форматированию и вывод информации, как правило, должны быть свои.
Если они реально нужны.
Например в самом scriptbrowser сейчас нет собственной функции просмотра списка макросов определяемых скриптом.
Потому что зачем дублироать, когда есть аж два макробраузера.

User avatar
HaRT
Moderator
Posts: 8109
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 67 times
Been thanked: 103 times

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

Post by HaRT » Thu 11 Aug, 2016 11:53

IgorZ wrote: Мне кажется, {версия, подверсия, правка, сборка[,статус(альфа,бета,релиз и т. п.)]} и привычней, и удобней в работе, и проще формализуется и верифицируется
И каким же это образом оно проще?!
В WinAPI есть поддержка 4-компонентных версий (притом без “статуса”), а в Фаре с LuaMacro где?
А в SemVer, прошу заметить, можно задать и сборку, и статус, и, что самое важное, очень чётко расписаны правила сравнения.
Фар есть инструмент, а не нянька. © 2009 DrKnS

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

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

Post by IgorZ » Thu 11 Aug, 2016 11:55

John Doe wrote:
IgorZ wrote: А вот алиасы представляются мне совсем уж излишней сущностью.
Ранее в теме обсуждалось.
Смысл: сокращённое наименование скрипта, с целью компактного представления в дополнительной колонке макробраузера.
Если у нас есть сколь угодно длинное описание, то вполне можно ввести ограничение на длину имени ,чтобы его можно было использовать в макробраузере. Или же вообще сделать ход конём: и вместо имени, и вместо алиаса использовать имя главного файла пакета без расширения. Всё равно в большинстве случаев это одно и то же. Хотя нет: некоторые переименовывают файлы, давая им длинные, "говорящие" имена, типа "автор-область_действия-имя_данное_автором.расширение", так что идея спорная. В общем, не надо плодить сущности: припоминаю на форуме как минимум один-два случая, когда один и тот же плагин искали не под тем именем: в качестве имени плагина употребляли имя файла, или что-то вроде этого. Так что не стоит создавать потенциал для ошибок своими руками. Проще всего сказать: "Имя может быть не длиннее 10 (к примеру) символов. Лишние будут обрезаться."
John Doe wrote:
IgorZ wrote: {версия, подверсия, правка, сборка[,статус(альфа,бета,релиз и т. п.)]} и привычней, и удобней в работе
По факту сам фар использует одно единственное число. И если вдруг когда-нибудь будет новый слом апи, то задействуется второе.
Это "проблема" не системы нумерования версий, и не фара, а команды разработчиков. Пресловутый человеческий фактор.
John Doe wrote:Плагины же используют кто во что гаразд.
В этом плане семантическое версионирование меня привлекает тем, что однозначно определяет порядок когда следует увеличивать каждую часть версии.
Что характерно: система из четырёх чисел тоже однозначно определяет. Эти числа так и называются: major, minor, patch, build. Тем не менее, это не мешает различнописателям игнорировать определение и нумеровать "кто во что гаразд". Повторюсь: человеческий фактор.
Всё "семантическое версионирование" сводится к тому, что те же самые числа записывают в другом формате. Он, возможно, легче воспринимается на глаз частью людей, но не стоит выдавать его за что-то новое.
John Doe wrote:А маленький дополнительный модуль, идущий в составе пакета никому не повредит.
Его функциональность избыточна и рассчитана скорее на встраивание в полноценную среду разработки. Отсюда следует, что количество потенциальных ошибок в нём тоже избыточно. А это не есть хорошо.
Второе замечание: таблица Луа из четырёх чисел будет автоматически проверена на корректность встроенными средствами на стадии загрузки скриптов. Строку придётся дополнительно проверять на корректность вручную модулю или же отдавать источник возможных ошибок браузеру как есть.
Третье замечание: с таблицей можно работать сразу. Строку надо или сначала преобразовать в таблицу, или вообще оставить как есть и при каждом обращении к ней дёргать модуль. А это всё дополнительные время обработки и загрузка процессора.

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

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

Post by IgorZ » Thu 11 Aug, 2016 12:07

John Doe wrote:
IgorZ wrote: дополнять таблицу дополнительными к содержащимся в nfo данными (пример - уже имеющееся FileName)
Вопрос до какой степени дополнять. Например, наличие под-скриптов, а может и их список.
Так сразу трудно сказать. Во всяком случае, сам факт наличия показывать бессмысленно. Ссылки из под-скриптов на над-скрипт есть? Тогда и ссылки из над- на под- логически напрашиваются.
Кроме того, я, в первую очередь имел в виду данные, вообще не извлекающиеся напрямую из nfo. Как имя файла.
John Doe wrote:
IgorZ wrote: функции, относящиеся к форматированию и вывод информации, как правило, должны быть свои.
Если они реально нужны.
Например в самом scriptbrowser сейчас нет собственной функции просмотра списка макросов определяемых скриптом.
Потому что зачем дублировать, когда есть аж два макробраузера.
Или я чего-то недопонял, или мы пишем разными словами одно и то же.

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

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

Post by IgorZ » Thu 11 Aug, 2016 12:41

HaRT wrote:
IgorZ wrote: Мне кажется, {версия, подверсия, правка, сборка[,статус(альфа,бета,релиз и т. п.)]} и привычней, и удобней в работе, и проще формализуется и верифицируется
И каким же это образом оно проще?!
В WinAPI есть поддержка 4-компонентных версий (притом без “статуса”), а в Фаре с LuaMacro где?
А в SemVer, прошу заметить, можно задать и сборку, и статус, и, что самое важное, очень чётко расписаны правила сравнения.
Для начала, следует определить, какие операции и кем или чем будут производиться с версиями. Я вижу всего две:
  • Автор ручками вписывает числа в nfo. Тут SemVer не участвует ни с какого боку. Есть некоторые формальные договорённости, соблюдение которых обеспечивается функцией доброй воли из личной библиотеки автора. Именно эти договорённости мы и обсуждаем. При этом программисту чисто подсознательно проще соблюдать те правила, которые зафиксированы в языке программирования - он и так привык их соблюдать.
  • Модуль считывает версию и использует её исключительно в операциях сравнения. Считывание таблицы однозначно удобнее для модуля - данные доступны напрямую, а не после танцев с бубном SemVer. Правила сравнения в случае таблицы не менее чётки и однозначны: числа сравниваются слева направо. Все правила, расписанные в SemVer, на самом деле существуют уже очень давно и соблюдаются всеми - я исключений не встречал. Да, статуса в 4-компонентной системе не предусмотрено, факт. Зато есть поле build, для Луа ненужное. Так что вполне можно оговорить, скажем, что в четвёртом поле "a", "a3", "b2", "p4", "r", "r2" означают первую альфу, третью альфу, вторую бету, четвёртый пре-релиз, релиз, вторую сборку релиза, оговорить, что пустое поле равно "r", а все прочие значения рассматриваются как комментарии. Такое соглашение будет ничем не хуже SemVer-овского. При этом потребует намного меньше накладных расходов в процессе работы модуля.
Так что имеем ряд преимуществ у таблицы и одно, легко компенсируемое преимущество у SemVer.
Кстати, чисто субъективно: v3.1.7b или {3,1,7,"b"} смотрится куда приятнее, чем v3_1_7_beta. Это я уже как эстет высказываюсь.

Shmuel
Posts: 5229
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 16 times
Been thanked: 151 times

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

Post by Shmuel » Thu 11 Aug, 2016 12:52

IgorZ wrote: Так что имеем ряд преимуществ у таблицы и одно, легко компенсируемое преимущество у SemVer.
Не вникал в детали всей дискуссии, но у SemVer есть одно довольно большое преимущество - это, по-факту, - стандартная, известная система. Не надо изобретать ещё один велосипед.

User avatar
HaRT
Moderator
Posts: 8109
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 67 times
Been thanked: 103 times

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

Post by HaRT » Thu 11 Aug, 2016 13:07

IgorZ wrote: Все правила, расписанные в SemVer, на самом деле существуют уже очень давно и соблюдаются всеми - я исключений не встречал.
Так и сам Semantic Versioning как инициатива существует уже достаточно давно (не знаю насчёт его реализации на Луа). А за нарушениями далеко ходить не надо — в плагине Observer при “breaking” изменении API для модулей (под-плагинов) версия самого плагина была изменена всего лишь с 1.10.1 на 1.11.0 — т.е. не в старшем номере версии. Поэтому использование системы, которая лишний раз подталкивает к стандартной нумерации версий и стандартному же изменению этих номеров, будет совершенно не лишне.
Фар есть инструмент, а не нянька. © 2009 DrKnS

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

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

Post by John Doe » Thu 11 Aug, 2016 15:54

Прежде всего в semver меня привлекают чётко прописанные правила формирования компонентов версии.
А как их записывать, это уже вопрос второй. Хоть бы и таблицей, как вы хотите.
Просто при наличии готового модуля работы с версиями я не вижу смысла как-то ограничивать свободу.
IgorZ wrote: При этом потребует намного меньше накладных расходов в процессе работы модуля.
Да какие там расходы)
IgorZ wrote: Кстати, чисто субъективно: v3.1.7b или {3,1,7,"b"} смотрится куда приятнее, чем v3_1_7_beta
semver.lua как сразу видно из описания переварит и v3.1.7b и {3,1,7,"b"} (b вероятно будет beta, но оно и к лучшему)

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

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

Post by John Doe » Thu 11 Aug, 2016 16:35

IgorZ wrote: Если у нас есть сколь угодно длинное описание, то вполне можно ввести ограничение на длину имени ,чтобы его можно было использовать в макробраузере
Сократить легко, а вот сократить так, чтобы осталось понятно, это уже автоматически не получится. В фаре например есть возможность указывать разный текст подсказки функциональным клавишам в зависимости от длинны.
IgorZ wrote:Во всяком случае, сам факт наличия показывать бессмысленно. Ссылки из под-скриптов на над-скрипт есть? Тогда и ссылки из над- на под- логически напрашиваются.
Не скажите, сам факт наличия тоже кое о чём говорит, например хотя бы то, что есть смысл открыть скриптбраузер для просмотра под-скриптов.
Ссылки из под-скриптов есть, как первичные данные, parent_id
А вот обратное - это уже аналитические данные. Сейчас они строятся каждый раз заново при вызове scriptbrowser.
Возможно стоит их сделать доступными прямо из regscript. Я не знаю, зависит от того, что потребует практика использования.
IgorZ wrote:
John Doe wrote:
IgorZ wrote: функции, относящиеся к форматированию и вывод информации, как правило, должны быть свои.
Если они реально нужны.
Например в самом scriptbrowser сейчас нет собственной функции просмотра списка макросов определяемых скриптом.
Потому что зачем дублировать, когда есть аж два макробраузера.
Или я чего-то недопонял, или мы пишем разными словами одно и то же.
Мне кажется мы всё же о разном.
Мой пример говорит о том, что функцию работы с макросами я использую готовую, а не изобретаю заново свою в скриптбраузере.
Соответственно в макробраузерах было бы логично так же, вызывать готовый скриптбразер.
Разумеется, какие-то данные о скриптах нужны и макробраузерам, поэтому я и обсуждаю интерфейс модуля.

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

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

Post by John Doe » Thu 11 Aug, 2016 19:41

IgorZ wrote: Тип и язык - для однозначной идентификации содержимого файла. Это нужно не автору скрипта (он и так всё о нём знает), а пользователю, чтобы в браузере можно было просто и однозначно манипулировать этими файлами.
[...]
И да, таблица - потому что с ней удобнее работать программно. [...]И намного проще расширить функциональность, если это понадобится позже.
У плагинов например нет такой функциональности, и я лично не чувствую чтобы мне её не хватало)
Но разумеется я не против любых улучшений, если их полезность будет продемонстрирована.
Что до таблицы, то её никогда не поздно добавить вместо строки, это ж lua.
IgorZ wrote:Если в головном файле в nfo будут перечислены все файлы, входящие в пакет, пользователю будет удобнее пользоваться информацией
Вроде бы это есть и сейчас. Если для чего-то понадобится одноуровневый список, то его легко построить.
Если понадобится в интерфейсе модуля — сделаем.
IgorZ wrote:Несколько nfo в одном файле кажутся мне идеологически неверными и профанирующими саму идею: навскидку, я изменю файл, а хранящаяся в другом месте nfo останется неизменной. Или же, я открываю файл и не вижу, к какому пакету он относится, потому что его nfo в другом файле.
Наличие nfo в самом файле не сильно поможет визуально, ведь там нет имени пакета, только id.
В остальном абсолютно согласен.
Но надо понимать, что скрипт может зарегистрировать себя только если он скрипт.
А lng/hlf в любом случае надо перечислять в files, или же регистрировать несколькими вызовами Info.
И вот тут я хочу акцентировать внимание, что наворачивать какую-то структура в files не имеет смысла поскольку вместо этого можно вызвать Info.
Тип файла, язык, это всё можно указать там (если понадобится).

P.S.
Надеюсь ничего не упустил и всё прокомментировал.

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

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

Post by IgorZ » Fri 12 Aug, 2016 11:21

Shmuel wrote:
IgorZ wrote: Так что имеем ряд преимуществ у таблицы и одно, легко компенсируемое преимущество у SemVer.
Не вникал в детали всей дискуссии, но у SemVer есть одно довольно большое преимущество - это, по-факту, - стандартная, известная система. Не надо изобретать ещё один велосипед.
Я не против самой системы нумерования версий - она, действительно, стандартна и родилась задолго до SemVer. Я не вижу необходимости затягивать сторонний модуль ради реально требуемой функциональности. Здесь требуется несколько процентов от возможностей SemVer.

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

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

Post by IgorZ » Fri 12 Aug, 2016 11:30

HaRT wrote: Поэтому использование системы, которая лишний раз подталкивает к стандартной нумерации версий и стандартному же изменению этих номеров, будет совершенно не лишне.
Предположим, я Ариман, решивший переписать Observer на Луа. Вчерне закончив собственно работу я начал заниматься оформлением. Увидел новомодную штучку nfo. Понравилось, решил добавить. Каким образом использование в regscript модуля SemVer заставит меня сделать идеологически правильный выбор между "1.0.0", "0.1.0" и "0.0.1", если в любом случае версия скрипта будет записываться ручками программиста по клавиатуре?
Вот честно, единственный возможный способ заставить авторов нумеровать версии в соответствии с определёнными правилами - тот же, что и с "жи/ши" - только вдолбить в подкорку. И никакие модули здесь не помогут. По крайней мере, пока в головы программистам не начнут встраивать чипы. Тогда уж можно будет записать модуль в чип и наслаждаться безупречной нумерацией версий.

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

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

Post by IgorZ » Fri 12 Aug, 2016 11:32

John Doe wrote:Прежде всего в semver меня привлекают чётко прописанные правила формирования компонентов версии.
А как их записывать, это уже вопрос второй. Хоть бы и таблицей, как вы хотите.
Я не против самих правил - это было бы откровенно глупо. Я не вижу необходимости в отдельном модуле для этого. С таблицей, на мой взгляд, проще работать. В конце концов, если очень хочется записывать версию строкой, для преобразования достаточно

Code: Select all

local tver = {}
tver.major, tvet.minor,tver.patch,tver.build = sver:match("^v(%d+)%.(%d+)%.(%d+)(%s*)$")
tver.build = tver.build = "" and "r" or (tver.build and tver.build:match("^([abpr]%d*)$"))
if not(tver.major and tvet.minor and tver.patch and tver.build) then обработчик ошибок версии end
John Doe wrote:Просто при наличии готового модуля работы с версиями я не вижу смысла как-то ограничивать свободу.
IgorZ wrote: При этом потребует намного меньше накладных расходов в процессе работы модуля.
Да какие там расходы)
"Курочка по зёрнышку клюёт". Зачем применять громоздкое решение там, где можно обойтись простым и лёгким?
John Doe wrote:
IgorZ wrote: Кстати, чисто субъективно: v3.1.7b или {3,1,7,"b"} смотрится куда приятнее, чем v3_1_7_beta
semver.lua как сразу видно из описания переварит и v3.1.7b и {3,1,7,"b"} (b вероятно будет beta, но оно и к лучшему)
Несколько строк кода переварят не хуже. Ведь кроме сравнения версий с ними никаких действий не требуется, так?

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

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

Post by IgorZ » Fri 12 Aug, 2016 11:32

John Doe wrote:
IgorZ wrote: Если у нас есть сколь угодно длинное описание, то вполне можно ввести ограничение на длину имени ,чтобы его можно было использовать в макробраузере
Сократить легко, а вот сократить так, чтобы осталось понятно, это уже автоматически не получится. В фаре например есть возможность указывать разный текст подсказки функциональным клавишам в зависимости от длинны.
Точно то же самое будет относиться и к алиасу - его тоже надо будет сокращать. И получится либо незапоминаемое зубодробительное обозначение, непонятное пользователю (и тогда не вполне ясно, зачем оно), либо удобное и короткое, которое быстро заменит в употреблении имя.
John Doe wrote:
IgorZ wrote:Во всяком случае, сам факт наличия показывать бессмысленно. Ссылки из под-скриптов на над-скрипт есть? Тогда и ссылки из над- на под- логически напрашиваются.
Не скажите, сам факт наличия тоже кое о чём говорит, например хотя бы то, что есть смысл открыть скриптбраузер для просмотра под-скриптов.
Ссылки из под-скриптов есть, как первичные данные, parent_id
А вот обратное - это уже аналитические данные. Сейчас они строятся каждый раз заново при вызове scriptbrowser.
Возможно стоит их сделать доступными прямо из regscript. Я не знаю, зависит от того, что потребует практика использования.
Я тоже не знаю наверняка. Но предполагаю, что их наличие упростит работу браузера. Так что, если делать это в regscript не будет сложно, лучше бы там - всё равно ведь идёт сканирование всех скриптов.
John Doe wrote:
IgorZ wrote:
John Doe wrote:Если они реально нужны.
Например в самом scriptbrowser сейчас нет собственной функции просмотра списка макросов определяемых скриптом.
Потому что зачем дублировать, когда есть аж два макробраузера.
Или я чего-то недопонял, или мы пишем разными словами одно и то же.
Мне кажется мы всё же о разном.
Мой пример говорит о том, что функцию работы с макросами я использую готовую, а не изобретаю заново свою в скриптбраузере.
Соответственно в макробраузерах было бы логично так же, вызывать готовый скриптбразер.
Разумеется, какие-то данные о скриптах нужны и макробраузерам, поэтому я и обсуждаю интерфейс модуля.
А, понял, кажется. Случай, когда браузер пакетов и макробраузер будут разными программами - не дублировать их функционал, а вызывать из одного другой, об этом речь? Я за. Но тут всплывает одна проблема, как мне кажется. Надо или унифицировать программный интерфейс между браузерами, или смириться с тем, что каждый браузер пакетов будет работать только со своим макробраузером, и наоборот. И как быть, я не уверен.

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

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

Post by IgorZ » Fri 12 Aug, 2016 11:33

John Doe wrote:
IgorZ wrote: Тип и язык - для однозначной идентификации содержимого файла. Это нужно не автору скрипта (он и так всё о нём знает), а пользователю, чтобы в браузере можно было просто и однозначно манипулировать этими файлами.
[...]
И да, таблица - потому что с ней удобнее работать программно. [...]И намного проще расширить функциональность, если это понадобится позже.
У плагинов например нет такой функциональности, и я лично не чувствую чтобы мне её не хватало)
Но разумеется я не против любых улучшений, если их полезность будет продемонстрирована.
Что до таблицы, то её никогда не поздно добавить вместо строки, это ж lua.
Плагины, как исторически сложилось, всегда лежат в отдельной папке. У скриптов всё гораздо сложнее. И не только с местоположением, но и с расширениями файлов. Те же языковые файлы: могу припомнить минимум три разных варианта назначения им имён и расширений. Поэтому и функциональность предлагается более богатая.
Небольшое отступление. Наличие огромного количества программ, вынужденно поддерживающих старые, уже негодные форматы файлов, данных и т. д., давно убедило меня, что лучше сразу продумать интерфейсы, чем потом мучиться с поддержкой и нового, и старого. И лучше тот интерфейс, который лучше поддерживает расширяемость. А таблица в этом смысле несоизмеримо лучше строки.
John Doe wrote:
IgorZ wrote:Если в головном файле в nfo будут перечислены все файлы, входящие в пакет, пользователю будет удобнее пользоваться информацией
Вроде бы это есть и сейчас. Если для чего-то понадобится одноуровневый список, то его легко построить.
Если понадобится в интерфейсе модуля — сделаем.
Предпочитаю сделать сразу, а не добавлять потом.
John Doe wrote:
IgorZ wrote:Несколько nfo в одном файле кажутся мне идеологически неверными и профанирующими саму идею: навскидку, я изменю файл, а хранящаяся в другом месте nfo останется неизменной. Или же, я открываю файл и не вижу, к какому пакету он относится, потому что его nfo в другом файле.
Наличие nfo в самом файле не сильно поможет визуально, ведь там нет имени пакета, только id.
В остальном абсолютно согласен.
Но надо понимать, что скрипт может зарегистрировать себя только если он скрипт.
А lng/hlf в любом случае надо перечислять в files, или же регистрировать несколькими вызовами Info.
И вот тут я хочу акцентировать внимание, что наворачивать какую-то структура в files не имеет смысла поскольку вместо этого можно вызвать Info.
Тип файла, язык, это всё можно указать там (если понадобится).
Несколько nfo в файле смотрятся и понимаются хуже, чем аккуратно оформленная вложенная таблица в единственном nfo.
John Doe wrote:P.S.
Надеюсь ничего не упустил и всё прокомментировал.
Вроде да, хотя уже не уверен окончательно с такой кучей портянок.

P. S.
На всякий случай: если в выходные не появлюсь, значит, интернет дома всё ещё не работает.

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

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

Post by John Doe » Fri 12 Aug, 2016 15:02

IgorZ wrote: Точно то же самое будет относиться и к алиасу - его тоже надо будет сокращать.
Человек в начале темы просил. Именно для компактного представления. А мне всё равно, обратите внимание это поле не поддерживается сейчас.
IgorZ wrote: Зачем применять громоздкое решение там, где можно обойтись простым и лёгким?
Простое и лёгкое тоже надо реализовывать, отлаживать, спустя время обнаруживать ошибки, и отлаживать снова.
Или взять готовый модуль на 10 килобайт.
IgorZ wrote: Но предполагаю, что их наличие упростит работу браузера.
Вот и я предполагаю.
Но реально в MacroBrowserAlt в ближайшее время внедрять не буду (его ещё доделать надо), поэтому пишите если что реально понадобится.
IgorZ wrote: Надо или унифицировать программный интерфейс между браузерами, или смириться с тем, что каждый браузер пакетов будет работать только со своим макробраузером, и наоборот.
Сейчас scriptbrowser поддерживает оба макробраузера, несмотря на отличие в интерфейсе.
IgorZ wrote: Предпочитаю сделать сразу, а не добавлять потом.
Это если бы наверняка знать что делать)
IgorZ wrote: Плагины, как исторически сложилось, всегда лежат в отдельной папке. У скриптов всё гораздо сложнее. И не только с местоположением, но и с расширениями файлов.
А я вот не против. Используйте любые новые поля, если они нужны для каких-то задач.
IgorZ wrote: И лучше тот интерфейс, который лучше поддерживает расширяемость. А таблица в этом смысле несоизмеримо лучше строки.
С таблицей тоже не будет сладко, и можно долго спорить что туда писать и в каком формате.
Поэтому пусть будет строка, в конце концов её очень легко заменить на таблицу когда это реально понадобится.
Если вообще понадобится, потому что пока всего предложенного можно достичь штатным путём.
IgorZ wrote: Несколько nfo в файле смотрятся и понимаются хуже, чем аккуратно оформленная вложенная таблица в единственном nfo.
А по-моему нечего там особо смотреть.
Постарался сделать всё так, чтобы не множить сущности.
И вроде бы удалось сохранить баланс между простотой и универсальностью.

Post Reply

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