[hwd]

Выкладываю свой вариант шаблона оформления плагинов AutoCAD. В прикреплённом архиве находится упакованный архив чистого шаблона и CHM-файл, в котором подробно разжёвано всё, что касается работы с данным шаблоном. Если кратко, то в основу шаблона положены следующие моменты:

• Ориентация на коллективную работу
• Самодокументирование приложения
• Автоматическая синхронизация содержимого документации в соответствии с состоянием настроек
• Простая возможность расширения существующего перечня локализаций
• Возможность программной/пакетной обработки плагинов
• Получение исчерпывающей информации о приложении открытием файла readme.html
• Управление сразу всеми имеющимися версиями приложения (скомпилированными под разные AutoCAD)

Если ещё более кратко, то шаблон построен на связке XML + XSD + XSLT.

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

UPD. Обновил архив - исправил серьёзную опечатку и добавил пример группирования и отображения команд.

UPD2. Завернул в шаблон программу Александра Ривилиса. Прикреплён внизу как DwgConvert.zip. Нужно распаковать архив и открыть файл readme.html.

UPD3. Перезалил оба архива. Внёс в шаблон некоторые правки, касающиеся визуального отображения, добавил в оглавление readme.html ещё один раздел, с помощью которого можно попадать в каталог нужной версии программы. Внёс изменения в chm-файл мануала.

UPD4. Перезалил оба архива. Внёс в шаблон некоторые правки, касающиеся визуального отображения, а так же расширил логику динамического формирования панели навигации readme.html - теперь в него можно добавлять произвольное количество групп с произвольным количеством позиций (помимо уже существующих). Частично изменил структуру и содержимое каталогов, например - в каталоге ./support находится только то, что не требует изменения (т.е. разработчику туда можно не заглядывать). Внёс соответствующие изменения в chm-файл мануала. Соответственно изменённому шаблону модифицировал пример приложения, построенного в соответствии с шаблоном.

UPD5. Перезалил оба архива. В шаблоне внёс изменение в файл appinfo.xslt, чтобы в таблицах имена команд, каталогов и файлов выделялись жирным шрифтом (так их легче читать), а так же исправил одну опечатку. Во второй архив добавил ещё два примера. Всё, более примеров выкладывать не буду - достаточно трёх.

UPD6. Перезалил оба архива. В шаблонах внёс некоторые изменения в файлы XSD, а так же в файл versions.xml, для возможности корректного описания LISP-программ. В архив samples, по просьбам телезрителей добавил пример упаковки LISP-сборника. В тот же архив упаковал и ещё одно приложение от Александра Ривилиса. В примере упаковки LISP-программ я, в качестве опять же примера, в таблицу загрузок добавил несколько записей, указав, что загружать следует все файлы с расширениями lsp, fas и vlx, хотя на самом деле в примере имеются только lsp-файлы.

[Дима_]

Сообщение от hwd Всё зависит от того, насколько хорошо в шаблоне всё было изначально спланировано и продумано.

прошло немного времени...

Сообщение от hwd Вчера мне пришла одна идея, в свете которой я начал модифицировать шаблон.

Держи "документацию" версий шаблонов у себя - тогда совместимость будет ТОЛЬКО твоей головной болью, а не всех использующих.

[hwd]

Сообщение от Дима_ прошло немного времени...

открой для себя такое понятие, как "предварительный вариант". Суть и содержимое не изменилось.

Сообщение от Дима_ Держи "документацию" версий шаблонов у себя - тогда совместимость будет ТОЛЬКО твоей головной болью, а не всех использующих.

Я как-нибудь разберусь.

[hwd]

Перезалил оба архива (в первом сообщении топика). Внёс в шаблон некоторые правки, касающиеся визуального отображения, а так же расширил логику динамического формирования панели навигации readme.html - теперь в него можно добавлять произвольное количество групп с произвольным количеством позиций (помимо уже существующих). Частично изменил структуру и содержимое каталогов, например - в каталоге ./support находится только то, что не требует изменения (т.е. разработчику туда можно не заглядывать). Внёс соответствующие изменения в chm-файл мануала. Соответственно изменённому шаблону модифицировал пример приложения, построенного в соответствии с шаблоном.

[hwd]

Перезалил оба архива. В шаблоне внёс изменение в файл appinfo.xslt, чтобы в таблицах имена команд, каталогов и файлов выделялись жирным шрифтом (так их легче читать), а так же исправил одну опечатку. Во второй архив добавил ещё два примера. Всё, более примеров выкладывать не буду - достаточно трёх.

[Do$]

Введение

Предоставление информации о том, пользователям каких доменных групп данное приложение будет загружаться автоматически

А это зачем? Разработчик заранее разве может знать, в каких сетях и с какими доменами будет работать приложение?

Визуализация файлов настроек, локализованных ресурсов, и т.п. При изменении настроек или др. данных, изменения тут же применяются и к документации, поскольку это одни и те же файлы

Это если использовать XML для хранения настроек.

Структура шаблона

bin

Мне тоже это название режет глаз. Может как-то по-другому назвать папку? “bin”, как я понимаю, - это от слова “binary”? То есть, подразумевается наличие в ней файлов двоичного кода, что не соответствует действительности для приложений AutoCAD. На мой взгляд, название наподобие “appfiles” больше соответствует содержанию.

support

Получается, что эта папка будет без изменений кочевать в каждую папку с приложением. Будет, к примеру, у меня 100 приложений - соответственно 100 копий этой папки. Может можно как-то по-другому?

Вообще, строго говоря, каталог <КаталогПриложения> не является самым верхним звеном, поскольку все каталоги приложений должны в свою очередь находиться в директории <КаталогКомпании>. Такой подход позволяет группировать приложения по их разработчикам.

Тогда, наверное, имеет смысл информацию о разработчике хранить не в папке приложения а в этой самой папке <КаталогКомпании>? Тогда и изменения вносить проще.
При этом, наверное имеет смысл расширить шаблон до папки <Приложения>? То есть, на 2 уровня вверх:
<Приложения>

<КаталогКомпании>

<КаталогПриложения>…

[hwd]

Сообщение от Do$ А это зачем? Разработчик заранее разве может знать, в каких сетях и с какими доменами будет работать приложение?

это не для разработчика, а для администратора, который работает в организации. Управлять приложениями на уровне доменных групп проще и целесообразней, чем на уровне каждого пользователя. Плюс юзер видит, членам каких доменных групп плагин автоматом грузится.

Сообщение от Do$ Это если использовать XML для хранения настроек.

Да.

Сообщение от Do$ Мне тоже это название режет глаз. Может как-то по-другому назвать папку? “bin”, как я понимаю, - это от слова “binary”? То есть, подразумевается наличие в ней файлов двоичного кода, что не соответствует действительности для приложений AutoCAD. На мой взгляд, название наподобие “appfiles” больше соответствует содержанию.

Многие приложения (например те, что написаны на .net) откомпилированный код хранят в подкаталоге "bin". Поэтому я его так и назвал, т.к. это имя однозначно говорит о том, что хранится в этом каталоге. Имя останется таким же, т.к. это несущественно и всем не угодить.

Сообщение от Do$ Получается, что эта папка будет без изменений кочевать в каждую папку с приложением. Будет, к примеру, у меня 100 приложений - соответственно 100 копий этой папки. Может можно как-то по-другому?

Такой подход обеспечивает независимость плагина от внешних факторов. Достаточно скопировать каталог плагина в нужное место, и он сразу готов к работе. Если содержимое каталога ./support выносить и делать общим для всех плагинов, то тогда появляется зависимость плагина от наличия внешних каталогов с ресурсами. Такая зависимость заставляет юзеров/администраторов CAD помнить, что помимо копирования каталога с плагином, дополнительно потребуется и копирование некоего каталога ./support.

Если бы была 100% уверенность в том, что плагин будет работать в чётко обозначенном окружении, то можно было бы сделать общий каталог ./support. Однако, скачав к примеру плагин из инета, пользователи ожидают, что достаточно скопировать на локальную машины лишь сам каталог приложения. У них зачастую не будет той корпоративной организации размещения плагинов, которая позволила бы вынести ./support во внешний файл. Надеюсь, что выразился ясно...

Сообщение от Do$ Тогда, наверное, имеет смысл информацию о разработчике хранить не в папке приложения а в этой самой папке <КаталогКомпании>? Тогда и изменения вносить проще.

Я отказался от такого подхода, решив упаковать эту информацию в плагин с целью уменьшения зависимостей (ситуация аналогичная той, о которой писал выше). Может легко сложиться такая ситуация, при которой юзер скопирует себе домой каталог с плагином, не подумав о том, что ему нужно копировать какую-то информацию из каталога автора.

Всё задумано и устроено так, чтобы каталог каждого плагина был независимым и самодостаточным.

Тогда, наверное, имеет смысл информацию о разработчике хранить не в папке приложения а в этой самой папке <КаталогКомпании>? Тогда и изменения вносить проще. При этом, наверное имеет смысл расширить шаблон до папки <Приложения>? То есть, на 2 уровня вверх: <Приложения> <КаталогКомпании> <КаталогПриложения>…

Так можно документировать путь вплоть до имени диска... Я исхожу из предположения, что любому программисту очевидно, что приложения должны быть собраны в одном месте, по аналогии, как это сделано в %ProgramFiles%. Однако для особо одарённых пользователей в документации приложения, на всякий случай, приводится такая информация (Оглавление -> О программе):

О размещении программы Не следует размещать программы где попало - создайте на локальной машине в удобном для вас месте каталог (далее по тексту - базовый каталог), в котором будете хранить свою коллекцию приложений. Непосредственно в базовом каталоге следует размещать подкаталоги, однозначно идентифицирующие их авторов (далее по тексту - каталог автора). Каталоги приложений следует размещать в соответствующих им каталогах авторов. В настройках Support File Search Path вашего AutoCAD должна присутствовать запись, указывающая на базовый каталог.

[Do$]

Сообщение от hwd Так можно документировать путь вплоть до имени диска...

Только до папки, прописанной в путях поддержки автокада, то есть папки <Приложения>. Мне думается, что можно было бы вынести readme в эту папку (вместе с папкой support), настроить его таким образом, чтобы через него можно было просмотреть информацию о любом приложении в папке и назвать как-нибудь типа "applications manager". В нем разместить проводник по приложениям с описанием приложения по формату имеющегося readme. В папках <КаталогКомпании> можно размещать информацию о компаниях, в единственном экземпляре на локальном компьютере. В итоге, мы получаем некий "фундамент", на который как "кирпичики" можно закладывать приложения. И все вместе будет образовывать систему приложений, оформленных по единому шаблону.
Ну вот к примеру, поменяется у А.Ривилиса номер телефона. Придется пройтись по всем приложениям и изменить контактную информацию. А если все будет в единой системе, то достаточно будет внести изменение только в 1 файл в соответствующей папке типа <КаталогКомпании>. Это только самое простое, что приходит в голову.
Конечно, при таком подходе, папка <КаталогПриложения> в отдельности не будет являться самодостаточной. Если это принципиально важно, то может можно разработать какой-то инструмент, позволяющий вычленить из системы самостоятельное приложение и возможность внедрить такое самостоятельное приложение в единую систему, то есть провести обратное преобразование.

[hwd]

Сообщение от Do$ Мне думается, что можно было бы вынести readme в эту папку (вместе с папкой support), настроить его таким образом, чтобы через него можно было просмотреть информацию о любом приложении в папке и назвать как-нибудь типа "applications manager". В нем разместить проводник по приложениям с описанием приложения по формату имеющегося readme.

Я уже писал о том, что на основе всех имеющихся readme.html будет динамически формироваться общая справка. В ней можно будет осуществлять поиск по ключевым словам. Это примерно то, о чём ты написал, но только лучше.

Сообщение от Do$ В папках <КаталогКомпании> можно размещать информацию о компаниях, в единственном экземпляре на локальном компьютере. В итоге, мы получаем некий "фундамент", на который как "кирпичики" можно закладывать приложения. И все вместе будет образовывать систему приложений, оформленных по единому шаблону. Ну вот к примеру, поменяется у А.Ривилиса номер телефона. Придется пройтись по всем приложениям и изменить контактную информацию. А если все будет в единой системе, то достаточно будет внести изменение только в 1 файл в соответствующей папке типа <КаталогКомпании>. Это только самое простое, что приходит в голову.

Я уже писал выше, что ставлю независимость приложения выше дублирования информации. Вручную ничего править не придётся - всё будет модифицироваться через GUI. Если у А.Н. Ривилиса изменится контактная информация - приложение изменит её сразу во всех его плагинах.

Сообщение от Do$ Конечно, при таком подходе, папка <КаталогПриложения> в отдельности не будет являться самодостаточной. Если это принципиально важно, то может можно разработать какой-то инструмент, позволяющий вычленить из системы самостоятельное приложение и возможность внедрить такое самостоятельное приложение в единую систему, то есть провести обратное преобразование.

Принципиально важно. Об инструменте упомянул выше.

Сейчас я пишу .Net API, на основе которого разработаю внешние приложения, управляющие работой таких плагинов.

[Do$]

А как тогда быть с файлами GUI?
Чтобы скопировав каталог с отдельным плагином, получить копию GUI, придется его также в каждую папку с приложением помещать. Так чтоли?

[hwd]

Сообщение от Do$ А как тогда быть с файлами GUI? Чтобы скопировав каталог с отдельным плагином, получить копию GUI, придется его также в каждую папку с приложением помещать. Так чтоли?

каждый плагин представляет собой самодостаточный, полностью документированный модуль. В нём человеческим языком прописано, что нужно сделать рядовому юзеру, чтобы тот смог этот плагин самостоятельно подключить у себя доми или на работе (если он работает сам по себе). За кулисами это прописано в формате XML, что позволит выполнить те же действия программно, упомянутыми тобой приложениями при желании.

то, о чём ты спрашиваешь - это отдельные, самостоятельные приложения. Их не нужно засовывать в каталоги каждого плагина. Часть из них предназначена для разработчика, чтобы вручную не править XML, другая часть - для администратора CAD, чтобы управлять настройками плагинов сразу для всех доменных пользователей. Дополнительные приложения облегчают работу с плагинами, но не являются необходимыми. Юзер может их поставить себе, а может и не ставить.

[Do$]

Ну что же, на мой взгляд, вполне работоспособная схема. Нерациональная, но работоспособная. Но это, опять же, только мое личное мнение.

[Дима_]

Сообщение от hwd Я уже писал выше, что ставлю независимость приложения выше дублирования информации..

Как вариант - дать возможност хранить ссылки на интернет ресурсы с библиотеками для загрузки (с соответственно проверкой наличия их уже)?

[hwd]

Сообщение от Дима_ Как вариант - дать возможност хранить ссылки на интернет ресурсы с библиотеками для загрузки (с соответственно проверкой наличия их уже)?

Если бы ты читал CHM-файл мануала, то знал бы, что это в шаблоне и так присутствует: Раздел Файлы шаблона -> readme.html. На обозначенной странице приведён пример, как можно добавлять произвольное количество дополнительных групп, каждая из которых содержит набор ссылок на произвольные ресурсы (по усмотрению разработчика).

[Boxa]

Рано или поздно у каждого накапливается куча програмулек и возникает жгучее желание все это упорядочить.
Андрей, спасибо за работу в этом направление.

ЗЫ.
Визуальный редактор для формирования обертки это оптимальное решение. ИМХО.
ЗЫЫ.
С интересом слежу за топиком.

[Дима_]

Я же цитирую - в контексте дублирования информации - на "сейчас" у Вас подразумеваеться, что "обертка" целиковая - посмотри лиспы, например, Крыса (а это то, что с моей точки зрения немалому количеству "пригодится", да и по факту используется) - там практически везде "подразумеваются" его-же библиотечные функции, которые лежат у него в подписи - то есть, что-бы "завернуть" его лиспы придется в каждый добавлять библиотеку (и заметь потом каждая будет загружаться - т.к. в каждую библиотечной функции, проверки "нет-ли меня уже в акаде" там естественно нет). Теперь спрошу еще раз - не видите ли Вы разумным, добавить в формат "обертки" (и как следствие в программу для сисадмина), возможности установки из "урезанной" обертки - то есть с АВТОМАТИЧЕСКОЙ загрузкой "библиолтечных" элементов из Интернета по необходимости.

[hwd]

Сообщение от Дима_ там практически везде "подразумеваются" его-же библиотечные функции, которые лежат у него в подписи - то есть, что-бы "завернуть" его лиспы придется в каждый добавлять библиотеку (и заметь потом каждая будет загружаться - т.к. в каждую библиотечной функции, проверки "нет-ли меня уже в акаде" там естественно нет).

как вариант, эти библиотеки можно так же завернуть в отдельный шаблон. Получившийся каталог выкладываем в том же каталоге, где находятся каталоги плагинов. В требованиях программы, которая использует эти библиотеки, нужно будет указать, что требуются эти библиотеки. Хотя конечно, в этом случае возникает нарушение целостности плагина, поскольку создаётся зависимость от внешних библиотек... Нужно подумать, мне бы очень не хотелось создавать зависимости, но... В общем - я подумаю на эту тему.

Теперь спрошу еще раз - не видите ли Вы разумным, добавить в формат "обертки" (и как следствие в программу для сисадмина), возможности установки из "урезанной" обертки - то есть с АВТОМАТИЧЕСКОЙ загрузкой "библиолтечных" элементов из Интернета по необходимости.

Не вижу разумным. В рамках организации юзерам всё должно устанавливаться из локального серверного репозитория, а не из интернета. Однако, пожалуй имеет смысл в файл appinfo.xml добавить раздел relations, в котором разместить информацию о зависимостях от внешних библиотек. В том же разделе указывать и то, откуда их можно скачать. Администратор CAD сам должен будет скачать из интернета эти библиотеки и выложить их в серверный репозиторий, через который они автоматом и попадут к юзерам.

т.к. в каждую библиотечной функции, проверки "нет-ли меня уже в акаде" там естественно нет

То, что лиспы не в состоянии определить факт своей загрузки - это очень плохо... Нужно подумать...

UPD
В каждую библиотеку, написанную им на AutoLISP или Visual LISP, Алексей Кулик может добавить определение глобальной переменной, имя которой будет уникально для каждого lisp-файла:

Код:

[Выделить все]

 (setq kulik-<fileName>-loaded T)

Вместо <fileName> в каждом LSP-файле должно быть указано его имя без пробелов и расширения. Да, в этом случае при переименовании файла, нужно будет не забывать переименовывать и имя переменной. Однако такой подход даёт возможность проверить, загружен ли нужный lsp-файл или нет. По аналогии др. лиспописатели смогут проверять свои файлы, указывая вместо префикса "kulik" свой собственный. Легко написать маленький bat или exe-файл, который пробежится по всем имеющимся lisp-файлам и добавит в них эти определения соответствующих этим файлам переменных. Файлы fas и vlx придётся править самим программистам вручную (вносить изменения в исходники и перекомпилировать их). Т.о. в лисп-программках можно определить факт загрузки той или иной библиотеки, путём проверки значения соответствующей этой библиотеки переменной.

[Дима_]

Сообщение от hwd То, что лиспы не в состоянии определить факт своей загрузки - это очень плохо... Нужно подумать...

Это неверное утверждение, могут просто по наличие имени функции: (if (not my-xxx-function) (defun my-xxx-function ...)) - просто это НИЧЕГО не меняет все равно ВЕСЬ файл загружаеться, "парсится" (т.к. надо определить конец закрывающей скобки), а поставить (if .... (load ...)) - не так-то просто ибо в лисп НЕ знает откуда он сам загружен (соответственно надо указывать ПОЛНЫЙ путь).
з.ы. Я ни в коем случае не хочу Вас учить "как делать правильно", просто вижу со стороны лиспа "явные тонкие места." Естественно, юзерами все должно устанавивться из "локального серверного", но ИХМО, тот-же репризиторий, должен делать CAD админ, с помощью спец. программы работающей с "обертками" - "простое" копирование к сожалению себя уже давно изжило, тем более, если я ничего не путаю, Вы собирались "подитоживать" все установленное на машине в 1 XML - что с моей точки зрения правильно - а это само по себе не произойдет. Так в этой-то программе (для CAD админа), при добавлении в формат соответствующих тегов, лично я (уверен что и Вы) не вижу сложности добавить проверку установленных необходимых компонентов, и при необходимости загрузки последних (ну или уведомлении, о невозможности, найти\получить их с заданного адреса).
з.з.ы - Все вышесказанное имеет рекомендательный характер.
Offtop: с гуишкой для ??? могу бескорыстно помочь - ибо дело в общем полезное

[hwd]

Сообщение от Дима_ Это неверное утверждение, могут просто по наличие имени функции: (if (not my-xxx-function) (defun my-xxx-function ...)) - просто это НИЧЕГО не меняет все равно ВЕСЬ файл загружаеться, "парсится" (т.к. надо определить конец закрывающей скобки), а поставить (if .... (load ...)) - не так-то просто ибо в лисп НЕ знает откуда он сам загружен (соответственно надо указывать ПОЛНЫЙ путь).

Выше я предложил проверять наличие переменной, однозначно идентифицирующей факт загрузки файла. Для того, чтобы проверить наличие переменной, не требуется загружать какой-либо файл и выполнять его парсинг. То, что лисп не знает, откуда он сам загружен - это я в курсе, но в данном случае определять это нет необходимости.

Сообщение от Дима_ тот-же репризиторий, должен делать CAD админ, с помощью спец. программы работающей с "обертками" - "простое" копирование к сожалению себя уже давно изжило

Мне проще взять zip-файл упакованного в шаблон плагина и положить его на сервер в нужный каталог, чем делать ту же операцию через дополнительную софтину. Зачем для этого действия писать программу копирования плагина в репозиторий? Так дойдёт и до написания программы, завязывающей программисту шнурки. Это нецелесообразно, т.к. скопировать файл в нужное место вручную - это всегда проще, чем запускать exe-файл, в котором через GUI указывать этот же файл для копирования.

Сообщение от Дима_ если я ничего не путаю, Вы собирались "подитоживать" все установленное на машине в 1 XML - что с моей точки зрения правильно - а это само по себе не произойдет.

Не совсем так. Если специально создавать отдельный XML файл, который был бы своего рода оглавлением всех имеющихся плагинов, то тогда после каждого добавления или удаления плагина из репозитория, придётся этот XML файл обновлять, дабы его содержимое соответствовало текущему составу репозитория.

Вместо этого я напишу маленькое приложение, которое при его запуске динамически в памяти формирует такой XML-документ и отображает его в себе посредством дочернего вэб-контрола. В этом же приложении будет динамически формироваться список ключевых слов и словосочетаний. Т.о. содержимое общей справки всегда будет соответствовать текущему составу репозитория плагинов.

Сообщение от Дима_ Так в этой-то программе (для CAD админа), при добавлении в формат соответствующих тегов, лично я (уверен что и Вы) не вижу сложности добавить проверку установленных необходимых компонентов, и при необходимости загрузки последних (ну или уведомлении, о невозможности, найти\получить их с заданного адреса).

Я всё же сторонник того, чтобы каждый плагин был полностью самодостаточен и независим от внешних ресурсов. Все необходимые сторонние библиотеки изначально должны присутствовать в каталоге версии плагина. Их можно разместить в отдельный дочерний подкаталог, чтобы тем самым отделить их от основного кода программ. При необходимости состав этого подкаталога всегда можно быстро обновить более новой версией библиотек. Грамотно написанный лисп, прежде чем начинать грузить др. лисп-файлы, должен проверить - есть ли в этом необходимость... Если эти файлы уже загружены др. плагином, то надобность в загрузке отпадает. Повторюсь - сделать это можно проверяя наличие переменной, соответствующей нужному лисп-файлу. Т.о. дополнительные сторонние библиотеки будут присутствовать в плагине, но загружаться будут только если в этом возникнет необходимость (если в лисп-коде программист выполнит соответствующие проверки).

с гуишкой для ??? могу бескорыстно помочь - ибо дело в общем полезное

В рамках нашей организации это является частью "AdminCAD" (от "администрирование AutoCAD"). "Гуишка" должна быть на WPF и построена в соответствии с паттерном MVVM, однако до GUI ещё далеко. Прежде чем писать GUI, нужно написать удобный API, поскольку все обозначенные выше приложения должны будут использовать именно этот API. В свободное время я займусь сначала именно API.

UPD
Вообще смысл создания данного топика был таков, чтобы программисты писали плагины, оформление которых было бы типовым. Такое оформление позволяет обратабывать их программно, извлекая необходимую для тех или иных задач информацию. Логическое продолжение этой идеи - создание в интернете репозитория, куда разработчики могли бы выкладывать оформленные в соответствии с данным шаблоном приложения. Пользователи различных организаций смогут программно мониторить состав этого репозитория и делать заявки своим администраторам CAD на предмет подключения очередного интересующего их модуля. Админ скачивает модуль в соответствующий каталог серверного репозитория и тот (модуль) автоматом становится доступным всем юзерам домена. Поскольку репозиторий русский, то и вся информация на нём + поиск по ключевым словам так же были бы на русском.

При желании, конечно же позднее можно было бы заморочиться и с системой оплаты (яндекс-деньги), дабы и российские разработчики смогли зарабатывать в инете через это дело при желании (магазин автодеска кладёт болт на русскоязычных программистов, говоря "PayPal" - читать как "работайте бесплатно".

Однако стоп... Эта идея (репозиторий в инете плагинов, оформленных по указанному шаблону), как я уже понял, не приживётся, поскольку даже сама идея приведения плагинов к общему знаменателю (не заикаясь ещё об инете) особого интереса не вызвала (один-два програмиста погоды не делают).

[Дима_]

Сообщение от hwd Если эти файлы уже загружены др. плагином, то надобность в загрузке отпадает. Повторюсь - сделать это можно проверяя наличие переменной, соответствующей нужному лисп-файлу.

1. А если не загруженна то что?? Откуда ее грузить?? Относительных путей, нет, абсолютных не может быть тем более - только написать - "Не установленна библиотека XXX" или встроить ее в каждый файл - что все равно будет их парсить при загрузке.
2. Переменные не нужны - имя функции это тоже переменная.

Я всё же сторонник того, чтобы каждый плагин был полностью самодостаточен и независим от внешних ресурсов.

хозяин барин...

[hwd]

Сообщение от Дима_ 1. А если не загруженна то что??

ты как-то уж очень невнимательно читаешь... Это (уже в который раз) я кому написал:

Сообщение от hwd Я всё же сторонник того, чтобы каждый плагин был полностью самодостаточен и независим от внешних ресурсов.

?
Это означает, что все необходимые библиотеки должны присутствовать в приложении, а не в интернете. Не загружена - значит в ведро такое приложение, т.к. это лишь неработающая часть приложения, а не полноценное приложение. Не вижу никаких трудностей в том, чтобы сразу добавить всё что нужно, не грузя этим пользователя или админа.

Сообщение от Дима_ 1. А если не загруженна то что?? Откуда ее грузить?? Относительных путей, нет, абсолютных не может быть...

А это кому предназначалось:

?
Кроме того, в CHM-мануале, прилагающемуся к шаблону, имеется раздел "Дополнительные каталоги поиска", в котором на конкретных примерах для LISP-приложений обозначено решение твоего вопроса.

Сообщение от Дима_ только написать - "Не установленна библиотека XXX" или встроить ее в каждый файл - что все равно будет их парсить при загрузке.

Сути этой фразы я не понял.

Сообщение от Дима_ 2. Переменные не нужны - имя функции это тоже переменная.

Тогда всё ещё проще.