[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-файлы.

[gomer]

улыбнуло

[hwd]

Сообщение от gomer улыбнуло

Как-то быстро тебя "улыбнуло", там в одной только документации 68 листов.

[Askarov]

Ниче не понял

[gomer]

Сообщение от hwd Как-то быстро тебя "улыбнуло"

не потому ли мегософтверные гиганты запихивают свои так называемые лицензионные соглашения в текстовый формат, чтоб их мог прочитать даже самый тупой юзер
зачем юзеру версия модуля, которую он не сможет подгрузить?
может не прав, но каталог bin - пережиток прошлого, атавизм дос, а вот где папка Help не понятно
насчет "правильного" решения... программист на лисп просто зашьет текстовый файл в модуль vlx и будет читать оттуда
насчет настроек... тут дело вкуса, реестр, ini, xml у каждого свои плюсы и минусы
насчет автоматической правки справки, ну, да, большая лень - реактивный двигатель прогресса
имхо. как-то уж слишком много эксэмеля...

[hwd]

2 gomer
ты ничего не понял.

[Do$]

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

[ShaggyDoc]

hwd, ты все правильно сделал. Такая система, безусловно, нужна. Вот только кому?

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

А ещё кому? Много ли у нас .NET-программистов? Много ли "всяких разных" программистов, работающих именно в MS Visual Studio 2010? Чтобы XSD и XSLT использовать? Можешь хотя бы оценочно назвать количество? 1? 10? 100000?

Или у тебя есть фирма с кучкой .NET-программистов? Которых надо "привести к общему знаменателю"?

А много ли таких "плагинов" вообще сделано? Хотя бы лично тобой? В России? В мире? Сколько именно, хотя бы примерно?
Можно примерный тематический список? А много ли таких плагинов сваливается на "адмнистраторов САПР" со стороны? Много ли таких "администраторов" вообще? 1? 10? 100000?

И какого уровня эти "плагины", чтобы на них затрачивать такие усилия по унификации и документированию? Уровня "dellayer" или, например, 3D-моделирования "чего угодно", или хотя бы уровня СПДС? А то вот мне попадалось .NET-приложение, которое ажно IP-адрес машины определяет и выводит в красивой рамочке.

Думаю, что эта, в принципе очень полезная работа, пока делается с прицелом на далекое-далекое будущее. Но тогда её надо на китайском документировать. А остальным пока "не в коня корм". Хотя я бы порекомендовал всем, кто берется за .NET-программирование, придерживаться этого "шаблона". Даже для "Hello Word".

По сути же шаблона мне кажется, что здесь обязательно должен быть и "шаблон" сценария инсталлятора.

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

Чтобы пользователю только оставалось нажимать кнопки и получать райское наслаждение.

[hwd]

Само собой, что в первую очередь себе. Ты её будешь придерживаться и будешь делать хорошие, унифицированные "плагины" (как ты их называешь). А ещё кому? Много ли у нас .NET-программистов? Много ли "всяких разных" программистов, работающих именно в MS Visual Studio 2010? Чтобы XSD и XSLT использовать? Можешь хотя бы оценочно назвать количество?

Этот шаблон создан не с прицелом на .NET - его можно использовать и для приложений написанных на Auto LISP, Visual LISP, VBA. В файле справки я писал, что рекомендую править XML файлы в IDE MS Visual Studio 2010, но на самом деле не принципиально в чём вы будете их править, но будет весьма удобно, если используемый вами редактор поддерживает проверку валидности XML на соответствие подключенных к нему XSD файлов. Я понимаю, что те, кто пишет на VBA или LISP не смогут воспользоваться указанной мною IDE, но они смогут использовать любую другую по их усмотрению.

Насчёт "кому это нужно" - это нужно и организации и пользователям, хотя они этого могут и не осознавать. Поясню... Если оформление приводится к единому знаменателю, то и пользователям будет проще работать с ними, т.к. они знают, что открыв readme.html они найдут всё, что им нужно. Более того - они уже знают, где именно в readme.html им следует искать интересующую их информацию. Такое оформление позволяет создавать приложения, которые управляли бы уже существующими плагинами и теми, которые появятся позднее. Например, можно написать приложение, которое отобразит пользователю полный перечень ключевых слов и словосочетаний, ассоциированных с командами, написанными во всех плагинах, построенных на основе шаблона. Юзер выбирает то, что ему нужно и автоматом будут открываться в браузере нужные страницы справок соответствующих плагинов с указанием команд, соответствующих его выбору. Т.о. пользователь может искать нужный ему функционал, не перелопачивая для этого кучу имеющихся приложений.

А много ли таких "плагинов" вообще сделано? Хотя бы лично тобой? В России? В мире? Сколько именно, хотя бы примерно?

Вы не поняли меня. Данный шаблон - представляет собой вариант обёртки, в которую можно упаковывать не только новые, но и уже существующие программы, используемые в организации. При этом писать код не потребуется - нужно просто внести в шаблон нужную информацию о программе. Чуть позже я покажу примеры упакованных в этот шаблон приложений. Это приложения написанные на ObjectARX, Auto LISP, Visual LISP и .NET. Я упакую в него приложения Александра Ривилиса, VVA, ну и парочку своих. Выложу их для наглядности, чтобы на конкретных примерах можно было пощупать как это работает.

По сути же шаблона мне кажется, что здесь обязательно должен быть и "шаблон" сценария инсталлятора.

Инсталлятор невозможен в принципе. Это ведь не приложение, а лишь обёртка. Каждый разработчик для своего приложения может создавать различного рода иерархию файлов и каталогов. Чтобы завернуть это в шаблон, нужно понимать, что делаешь. Если, к примеру, автор в текстовом файле всё в одном месте прописал: перечень команд, системные требования и т.п., то как инсталлятор узнает где какая информация и выдернет её, чтобы заполнить в шаблон? Сейчас ведь все пишут как им Бог на душу положит, а значит упаковку каждого приложения придётся делать вручную. Да, это придётся сделать один раз, но много времени это не займёт и оно того стоит (имхо). И ещё - упаковкой занимается не пользователь, а разработчик! Т.е. он сам своё творение упаковывает в шаблон. Пользователь юзает готовый результат. Если упаковывать нужно и чужой код, который уже имеется у юзеров, то этим может заняться администратор CAD или человек, выполняющий его обязанности.

И какого уровня эти "плагины", чтобы на них затрачивать такие усилия по унификации и документированию?

это приложения, которые написаны в самой компании, либо притащенные юзерами из инета.

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

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

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

[ShaggyDoc]

но будет весьма удобно, если используемый вами редактор поддерживает проверку валидности XML на соответствие подключенных к нему XSD файлов.

А ты знаком хоть с каким-то таким редактором? Я их вроде бы все испробовал. И ничего лучше обычного Notepad ++ не обнаружил.
XSD придумала Microsoft сначала для себя. Потом этот стандарт признали. Но без него прекрасно можно обойтись, что подавляющее большинство программистов и делает. Как и без MSXML обходятся.

Вот я сейчас заканчиваю программу, в которой должен быть экспорт в XML на основе 24 вложенных XSD. Пробовал с MSXML, раз уж он XSD поддерживает, и отказался. Слишком все по-Майкросовтовски неуклюже получается. Но это несущественные детали.

Так как все-таки насчет количества Net-приложений и Net-программистов? "Скока в штуках"?

[hwd]

Сообщение от ShaggyDoc А ты знаком хоть с каким-то таким редактором? Я их вроде бы все испробовал. И ничего лучше обычного Notepad ++ не обнаружил.

дома я часто использую Notepad++. Вы можете подгрузить к нему модуль, который будет проверять ваш XML файл на предмет валидности для указанного вами XSD - я себе его подгрузил и регулярно использую. Работать с XML можно и в бесплатной MS Visual Studio Express, либо в MonoDevelop, SharpDevelop - было бы желание. Те, кто хотят - ищут возможности, а те кто не хочет... их никто не заставляет.

Сообщение от ShaggyDoc XSD придумала Microsoft сначала для себя. Потом этот стандарт признали. Но без него прекрасно можно обойтись, что подавляющее большинство программистов и делает. Как и без MSXML обходятся.

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

Сообщение от ShaggyDoc Так как все-таки насчет количества Net-приложений и Net-программистов? "Скока в штуках"?

В нашей компании я единственный программист. Сколько написал программок для пользователей - не считал, и считать не собираюсь.

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

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

[gomer]

Сообщение от hwd основная масса программистов не интересуется подобными темами

Конечно, нам же удобнее писать абы как, с учетом цейтнота, привязывая свои мега творения к диску с буквой зю

Сообщение от hwd притащенные юзерами из инета

ну, таким товарищам никакой менеджер не нужен, они себе кнопку нарисуют и будут пользоваться, хоть котом в мешке

Сообщение от hwd Я никого не заставляю использовать XML

не заставляете, но настойчиво предлагаете ^_^

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

трудно понимаемая фраза в контексте всего вышесказанного

Сообщение от ShaggyDoc "Скока в штуках"?

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

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

как тупому юзеру мне не хочется знать таких сложных вещей, я знаю кнопку F1, в любой момент я ее могу нажать и хочу получить информацию о команде, че де и как, В автокаде есть такая возможность, правда не все программисты ее используют, а вы про программы, управляющие программами, а как насчет нажать Alt+Я и Ф и получить окошко Конструктора Ферм? У кого есть такое? А как насчет нормального редактора псевдонимов команд?

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

те есть открываю я автокад, а мне дюжина сообщений, мол не хотите ли ознакомиться возможностями новых модулей принесенных Васей Пупкиным из инета? и вот я сижу закрываю эти окошки ознакамливаюсь с возможностями (как вариант просто забываю про них), а время то течет и все 10 автокадов на моей машине ждут моих рук...
Кстати автодеск вроде уже добавила возможность скачивания модулей из песочницы, ну и как бороться с такими нестандартными приложениями?

[hwd]

2 gomer
то, что я предложил в начале топика - это готовый результат, который можно пощупать. то, что ты написал выше - это словоблудие. тебя никто не заставляет использовать это. адресовано тем, кому интересно.

[gomer]

Сообщение от hwd то, что ты написал выше - это словоблудие

У мну ридми не открылся пришлось все выкладывать на диск...
hwd, поражаюсь вашему трудолюбию
я вот грешным делом подумывал сложить библиотечки А.Ривилиса в папочку {MyApp} сделать менюшку {MyApp.mns}, прописать макросы и подсказки, прописать загрузку библиотечек в {MyApp.mnl} и добавить папку {MyApp} в пути поддержки... и было б мне счастье, да вот как-то руки не доходят, хотя на все про все у мну вышло бы пол часа времени, максимум

[hwd]

ключевой момент не то, что всё собрано в readme.html, а то, что всю информацию о приложении можно получить программно, т.к. шаблон представляет собой своего рода типовой интерфейс.

[gomer]

а разве нельзя программно извлекать инфу из самой библиотеки, это самая достоверная информация: производитель, версия, язык, описание...

[hwd]

Сообщение от gomer а разве нельзя программно извлекать инфу из самой библиотеки, это самая достоверная информация: производитель, версия, язык, описание...

Вот некоторый список вопросов:

1. как ты из них извлечёшь информацию о том, нужно ли в File Search Path добавлять каталоги поиска, и если нужно, то какие?
2. Как ты из них узнаешь, регистрируют ли они сами себя в реестре на предмет автозагрузки (чтобы не грузить то, что и без тебя будет грузиться)?
3. Как ты узнаешь, какие именно из библиотек нужно загружать и в какой последовательности? ведь нередко грузить нужно одну-две, а уже те, в свою очередь, тянут остальные вагоны.
4. Как ты узнаешь перечень определённых в библиотеке команд и ключевых слов, связанных с ней?

[gomer]

1. Все равно придется добавлять по определению
2. и 3. это разные весчи: одиночный модуль, которому вовсе не нужна автозагрузка (а если она есть, то это тот еще гемор) и комплексный вагон, который монополизирует автокад и сам себя контроллирует, на программном, а не файловом уровне
4. вопрос не ко мне... но как то же автокад это делает

[Дима_]

Я думаю пока ты (или еще кто) не напишешь гуишку для "полуавтоматической" обертки такой "сопроводиловкой" + программу для автоматической установки/манипулирования софта(ом), на его основе, количество человек пользующимся твом шаблоном будет стремиться к единице. Ибо разбираться в кучке чужих XML'ов - никто на это время тратить не будет - Крыс как-то предлагал, весьма толковый и НЕСЛОЖНЫЙ "формат" оформления лисп программ - им и то, по факту, больше ни кто не пользуеться, а уж это творение и подавно. Скажу, честно, я хоть и прекрасно умею пользоваться XML'ом - искренне считаю, что это формат НЕ ДЛЯ РУЧНОЙ ПРАВКИ - только софтовой, оно-же как и весь "софт" предолагающий изменение настроек "дружелюбным" XML редактором - есть "сыроделка."

[ShaggyDoc]

как ты из них извлечёшь информацию о том, нужно ли в File Search Path добавлять каталоги поиска, и если нужно, то какие?

Правильная программа с инсталлятором сделает это сама

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

Правильная программа с инсталлятором сделает это сама

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

Правильная программа с инсталлятором сделает это сама

Как ты узнаешь перечень определённых в библиотеке команд и ключевых слов, связанных с ней?

Правильная программа с инсталлятором сделает это сама. Сделает нормальное меню, панели инструментов. А "перечень команд" будет в этом меню. А перечень "ключевых слов" будет выводиться при работе в командной строке и в контекстном меню. И в правильной программе имеется правильный файл справки, который не надо где-то разыскивать.

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

Инсталлятор невозможен в принципе

Это самое большое твое заблуждение. Так как

В нашей компании я единственный программист. Сколько написал программок для пользователей - не считал, и считать не собираюсь.

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

[hwd]

Сообщение от ShaggyDoc Правильная программа с инсталлятором сделает это сама

Загляните в раздел "готовые программы". Много вы там найдёте "правильных программ с инсталлятором"? А те, которые имеются - после инсталляции имеют ли плагины единую структуру? Я исхожу из действительности - юзеры тащат из инета то, что найдут, а находят они далеко не всегда msi. Да и то, что софтина упакована в msi, вовсе не является гарантом качества самой софтины (чтобы создать msi много ума не надо).

Инсталлятор невозможен в принципе Это самое большое твое заблуждение.

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

А перечень "ключевых слов" будет выводиться при работе в командной строке и в контекстном меню.

в "командной строке" и в "контекстном меню" ключевые слова никому не нужны. Ключевые слова нужны для возможности поиска в справочной системе.

И в правильной программе имеется правильный файл справки, который не надо где-то разыскивать.

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

Правильная программа с инсталлятором

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

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

Вообще-то есть у меня такая практика. Поверьте, вы не единственный, кто умеет создавать msi, и совершенно не факт, что вы это делаете лучше меня.

ты пишешь "программки" да какие-то "плагины", а не приложения

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

Я думаю пока ты (или еще кто) не напишешь гуишку для "полуавтоматической" обертки такой "сопроводиловкой" + программу для автоматической установки/манипулирования софта(ом), на его основе, количество человек пользующимся твом шаблоном будет стремиться к единице.

Абсолютно согласен, и более того - это в ближайших планах. Шаблон и документацию я выкладывал для того, чтобы желающие могли детально ознакомиться с тем, как что устроено и что с чем взаимодействует. Имхо - помимо того, чтобы иметь возможность юзать GUI, желательно чтобы программист понимал, что там на самом деле за кулисами происходит. Именно это и разъясняется в выложенном мною CHM-файле.

[Дима_]

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

Андрей, все что я скажу дальше ТОЛЬКО мое видение данного вопроса. Вот этот подход изначально губительный (я сам на нем попался, когда "документировал" формат настроек в одной "заказной" софтине, правда не имеющей никакого отношения к автокаду, но не суть). Ты сейчас задаешь формат и его открываешь, причем не просто открываешь, а декларируешь - мол давайте пользоваться, а завтра, например, ты решаешь, что можно еще добавить "скрины" софта, или подумаешь, что все данные о всех установленных программах лучше собирать (автоматом) на пользовательской машине в 1 XML и из него уже "рулить" (повторюсь - это только для примера). Да XML легко расширяется, но тебе "для совместимости" придеться тащить все "хвосты" старых версий (которые быть может в последствии, ты поймешь что хранить лучше в другом, более широком, формате, либо же они вобще "не приживутся") - то есть получатся либо ограничения, либо "пятикратное" дублирование одного и того же, в разных форматах, для всех предудущих версий. ИХМО правильно инкапсулировать внутри проги, а там вороти что хочешь, не зря начиная с 2010 версии автодеск свои настройки в xml зазиповал - нечего туда "врукопашную" лезть, есть гуишка, есть API (кстати тебе тоже вариант для размышлений). И программа "любой" версии будет без проблем вытаскивать в нужном формате заданную ее "сегодняшним" функционалом версии из любой обертки. То есть мое резюме такое - формат пряч - "ГУЙ" юзерам, АПИ программистам.

[hwd]

а завтра, например, ты решаешь, что можно еще добавить "скрины" софта

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

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

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

То есть мое резюме такое - формат пряч - "ГУЙ" юзерам, АПИ программистам.

В идеале каталог support конечно же должен быть представлен неким zip файлом, у которого изменено расширение дабы юзер в него не лез. Однако, насколько мне известно, в XML нельзя указать привязку к XSD и XSLT находящимся в архиве. Поэтому пока все эти "внутренности" собраны в отдельном каталоге. Юзеру нет нужды лезть туда. Всё что ему нужно находится в readme.html, который по сути и представляет собой GUI для юзеров. API разработчику будет представлено в виде GUI, где в диалоговом окне он будет заполнять данные, а те автоматом будут записываться в соответствующие XML файлы.

[Дима_]

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

Вот это как раз то, что мне в последствии и пришлось делать - гемор эти конверторы, а если изначально декларировать только GUI/API доступ - то все конвертации делаются прозрачными для пользователя. Время которое все меняет течет на удивление быстро, а "беда" XML в том что он сколь угодно "масштабируеться" - но только в сторону увеличения.

[hwd]

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

Всё зависит от того, насколько хорошо в шаблоне всё было изначально спланировано и продумано. Быстро возникающая потребность в модификации - следствие плохой предварительной проработки темы. Выложенная версия шаблона предусматривает всё что нужно для работы с плагином. Однако даже если мне и придётся со временем написать какой-нибудь конвертер, то пишется он очень просто, благодаря наличию технологии LINQ to XML. А вообще, волка бояться - в лес не ходить.

Сообщение от Дима_ а если изначально декларировать только GUI/API доступ - то все конвертации делаются прозрачными для пользователя.

Как я уже выше заметил - пока что потребность в модификации на горизонте не маячит. О каком API вообще речь? Отображение всей информации берёт на себя браузер. При этом он руководствуется технологией XSL. Что за API и как ты ему его укажешь, чтобы он в соответствии с этим API отображал информацию? Что-то я тебя не понял. Насчёт GUI я уже писал выше - он появиться для программиста для удобства заворачивания в шаблон уже готовых плагинов. GUI для юзера - это файл readme.html.

[Дима_]

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

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

В моем случае это зависело, от внезапной платной "хотелки", но в любом случае я не думаю, что, например, автодеск плохо "продумывают", но тем не менее форматы у них "пляшут" (хотя причина безусловно не только в этом).

[hwd]

Сообщение от Дима_ Я имею в виду что по моему правильно, делать не формат, а прогу для заворачивания плагинов в некий формат

Прежде чем заворачивать в какой-то формат, этот формат для начала должен быть определён.

Сообщение от Дима_ и прогу для просмотра этих "свертков", модифификации, автообновлении по версии, помощи, установке итд. - то есть для работы с ними - это GUI.

В данном случае программой для просмотра, т.е. GUI, является обычный браузер. Зачем изобретать велосипеды со своими программами просмотра, когда можно воспользоваться тем, что у всех имеется под рукой?

Сообщение от Дима_ А также, в идеале - сделать открытый API интерфейс, для "продвинутых" программеров, чтобы они не с твоей гуишкой "маялись", а сами парой строк кода все нужное установят.

"продвинутые" программеры уже получили этот API в виде подробных XSD схем, описывающих формат каждого XML файла. Программно они могут менять XML как хотят, главное, чтобы это соответствовало схеме. В каждом языке программирования свои инструменты работы с XML. Писать API в виде библиотек под каждый язык, в данном случае дело неблагодарное и невосстребованное. Для .Net я напишу такой API, благо что много времени на это не уйдёт, но для остальных языков - не вижу смысла в виду отсутствия интереса. А если интерес и появится, то под свой язык программист LISP напишет API гораздо грамотней, нежели это сделал бы я.

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

А я думаю, что причина как раз таки в этом.

[gomer]

Сообщение от hwd В данном случае программой для просмотра, т.е. GUI, является обычный браузер. Зачем изобретать велосипеды со своими программами просмотра, когда можно воспользоваться тем, что у всех имеется под рукой?

Обычный браузер - понятие гипотетическое

[hwd]

Сообщение от gomer Обычный браузер - понятие гипотетическое

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

[Дима_]

Немного оффтоп, но скажем так для направления мысли - есть "малоизвестный" офисный пакет, в котором файлы храняться в виде зазипованных XML'ов под разными именами docx, xlsx... и для их редактирования есть "GUI-шка", а для программеров - (хоть внутри и простой для программиста XML) есть свои API для обращения и работы с документами, а если кто и работает с их документами посредством разархивирования и вытягивания XML информации - либо "творцы" аналогичных пакетов (для совместимости), либо полные извращенцы.
Ставить обычный браузер для просмотра - конечно можно, но лично я бы, смотря вперед, подстраховался, и использовал хоть тот-же System.Windows.Forms.WebBrowser() - чтоб была возможность от него откреститься (если ВНЕЗАПНО станет понятно что html юзера в данном случае, несет дублирующею и хаотичную информацию - когда "програмная" разрастеться) или если чего - "довесить" нужную обработку - то есть если ставить html для просмотра - то контролируемый и "сгенерированный" програмой-же (чтоб для его создания не требовалось, "кучка" софта, который, кроме как для этого может быть и не нужен (тому-же листописателю), да еще и в нормальном функционале, может быть платный).

[gomer]

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

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

[bernata]

переходите уже на личности... читаю - читаю... а вы всё в рамках приличия

[hwd]

Сообщение от gomer у мну 3 браузера: ослик 6, опера и лис

добавь к этому списку хром и сафари - это и будет перечень обычно используемых браузеров.
2 Дима_
Честно говоря, я ничего не понял из написанного. Есть кое-какие идеи по поводу доработки шаблона. На выходных внесу некоторые изменения + дополнения... После чего обновлю документацию и пример. На след. неделе сделаю GUI, с помощью которого можно будет упаковывать плагины. документацию, шаблон и пример обновлю, дабы уже окончательный вариант находился по ссылкам. Поскольку тема интереса не заимела - на этом заканчиваю опубликовывать материал.

[gomer]

Сообщение от bernata переходите уже на личности... читаю - читаю... а вы всё в рамках приличия

не тюкайте

Сообщение от hwd тема интереса не заимела

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

[Do$]

Сообщение от hwd тема интереса не заимела

Не согласен. Мне это очень интересно! На выходных буду разбираться что к чему, пока банально нет времени . Ну вы тут особо не скучаете Тема самая динамично растущая в этой ветке, а говоришь нет интереса

[hwd]

Сообщение от Do$ Тема самая динамично растущая в этой ветке, а говоришь нет интереса

Основная масса контента в топике - споры ни о чём, так что размер в данном случае не показатель.

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

У меня корректное отображение наблюдается в Internet Explorer 8/9, Google Chrome, Opera и Safari.

FireFox игнорирует тэги форматирования и отображает их как текст. Браузеры никогда не отличались особой совместимостью (к сожалению).

[Salt]

Сообщение от hwd Браузеры никогда не отличались особой совместимостью (к сожалению)

Вот потому Дима_ и предлагает для просмотра, хотя бы той же readme.html, использовать System.Windows.Forms.WebBrowser(), т.е. просмотрщик, в основе которого всегда лежит IE (именно такой "самодельный" просмотрщик от Autodesk открывается, когда ты из автокада 2012(13), нажав кнопочку [x], переходишь на сайт Autodesk Exchange)
Но ИМХО, я бы отказался от XSLT (от трансформации в HTML) и написал просмотрщик (не веб-браузер), напрямую читающий и визуализирующий информацию из XML файлов, и включил бы его, в качестве обязательного компонента, в состав решения.

На след. неделе сделаю GUI, с помощью которого можно будет упаковывать плагины

Это как раз то второе, что хотелось Диме_. Т.е., в идеале, дать возможность не очень продвинутым авторам плагинов вообще не соприкасаться с лежащими в основе XML-форматами. А еще лучше, это GUI сделать единственным сертифицированным способом редактирования XML и, тем самым, изолировать пользователей (авторов плагинов) от возможных будущих изменений XML-форматов.

Категорически нужна еще третья вещь - загрузчик плагинов (насколько я в курсе, от у тебя готов, или почти готов). И тогда есть все шансы получить целостное, вполне промышленное решение. Этим решением, помимо тебя самого, сможет воспользоваться любой заинтересованный CAD-администратор.

p.s.
ИМХО.
Плагин для автокада не должен требовать инсталлятора. Нужно брать папку с должным образом оформленным плагином, класть её в положенное место в сети или на локальном компьютере и на этом всё!. Об остальном, на основе имеющейся в папке информации, позаботится специализированный загрузчик.
Андрей Бушман принципиально делает всё правильно. Можно спорить лишь о деталях. Приложения из "магазина Autodesk" именно таким (похожим) образом и документируются/распространяются/инсталлируются. Но их (автодеск) конкретное решение непригодно для промышленной эксплуатации в рамках института, где трудится Андрей.

[gomer]

Сообщение от hwd Браузеры никогда не отличались особой совместимостью (к сожалению).

вот поэтому

Сообщение от gomer Обычный браузер - понятие гипотетическое

Сообщение от Salt Нужна еще третья вещь - загрузчик плагинов (насколько я в курсе, от у тебя готов, или почти готов). И тогда есть все шансы получить целостное, вполне промышленное решение. Этим решением, помимо тебя самого, сможет воспользоваться любой заинтересованный CAD-администратор.

Идея не нова, на лиспе такое было написано за царя гороха еще

[Salt]

Идея не нова, на лиспе такое было написано за царя гороха еще

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

[hwd]

Сообщение от Salt Вот потому Дима_ и предлагает для просмотра, хотя бы той же readme.html, использовать System.Windows.Forms.WebBrowser(), т.е. просмотрщик, в основе которого всегда лежит IE (именно такой "самодельный" просмотрщик от Autodesk открывается, когда ты из автокада 2012(13), нажав кнопочку [x], переходишь на сайт Autodesk Exchange)

Можно и так. Я подумаю над этим вариантом. Хотя можно и просто прописать в readme.html, что для его корректного отображения следует использовать такие-то браузеры.

Сообщение от Salt Но ИМХО, я бы отказался от XSLT (от трансформации в HTML) и написал просмотрщик (не веб-браузер), напрямую читающий и визуализирующий информацию из XML файлов, и включил бы его, в качестве обязательного компонента, в состав решения.

Категорически не согласен. XSLT позволяет абстрагировать визуализацию от содержимого. При необходимости, в XML файлах можно указать ссылку на др. XSLT и данные будут представлены совершенно иначе. С помощью XSLT данные можно представлять в любом формате, например в txt, xml (иной структуры), html, rtf, pdf, csv и т.п. Кроме того, разработчик может часть информации прописать не просто текстом, а в виде разметки html, дабы эта информация была оформлена некоторым особым видом. XSLT распознает это и корректно отобразит.
В шаблоне XSLT используется "за кулисами". Вчера мне пришла одна идея, в свете которой я начал модифицировать шаблон. Теперь он будет организован более "красиво". Например в каталоге ./support будут находиться только те файлы, которые необходимы для визуального представления, т.е. это файлы XSLT, XSD и "CSS" (т.е. XML вариант CSS контента). В этот каталог собраны статические файлы, содержимое которых не потребуется менять. Программисту нет необходимости лезть в тот каталог. Собственно собраны туда затем, чтобы случайно не изменили чего-нить. В файл readme.html будет добавлена некоторая дополнительная информация, полезная как пользователям, так и разработчикам...

Сообщение от Salt Сообщение от hwd На след. неделе сделаю GUI, с помощью которого можно будет упаковывать плагины Это как раз то второе, что хотелось Диме_. Т.е., в идеале, дать возможность не очень продвинутым авторам плагинов вообще не соприкасаться с лежащими в основе XML-форматами. А еще лучше, это GUI сделать единственным сертифицированным способом редактирования XML и, тем самым, изолировать пользователей (авторов плагинов) от возможных будущих изменений XML-форматов.

Не понял насчёт "сертифицированного". GUI однозначно будет построен таким образом, чтобы с его помощью можно было выполнять все действия, которые потребуются. Отдельный GUI будет для работы с файлами настроек (т.е. теми файлами которые хранятся непосредственно в подкаталоге "./settings".

Сообщение от Salt Плагин для автокада не должен требовать инсталлятора. Нужно брать папку с должным образом оформленным плагином, класть её в положенное место в сети или на локальном компьютере и на этом всё!.

Согласен на все 100%. Однако те, кому всё же не терпится - всегда могут результат упаковки засунуть в msi-пакет. Я этого делать не буду, т.к. моё видение таково, что админ должен просто скопировать плагин в определённое место на сервере (в репозиторий организации), а тот автоматом "раскатается" на локальные машины. Плагин автокада - это отдельный независимый модуль, как камешек в мозаике. Плагин самодостаточен и не должен влиять на работу др. плагинов, иначе начинает образовываться цепочка зависимостей плагинов друг от друга, что не есть хорошо. Плагин - это как маленькая функция в программировании, решающая свою конкретную задачу. Должна иметься возможность заменить один плагин другим, без фатального влияния на др. плагины. Это то, чего я придерживаюсь при написании плагинов под AutoCAD. Установка плагина должна быть как можно более простой. Нет более простого способа, чем просто скопировать шаблон в нужное место (имхо).

Сообщение от Salt Категорически нужна еще третья вещь - загрузчик плагинов (насколько я в курсе, от у тебя готов, или почти готов).

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

1. Отдельное внешнее exe приложение будет анализировать имеющиеся версии плагинов и в формате XML формировать сводную информацию о том, под какую версию AutoCAD имеются какие плагины и в каких каталогах они находятся.
2. Будет иметься отдельное exe приложение, имеющее GUI, с помощью которого юзер будет просматривать информацию о том, какие плагины имеются в наличии, под какие версии AutoCAD и каков их функционал. Напротив тех плагинов, которые ему интересны, юзер будет ставить галочку, тем самым пометив их в автозагрузку. Те плагины, которые администратором CAD помечены в автозагрузку как обязательные, будут подсвечены серым цветом, чтобы юзер не мог снять галочку. Информация записывается в XML, хранящийся в профиле пользователя. То, что помечено обязательным к загрузке - хранится в др. месте, дабы юзер не мог на это повлиять (управление у администратора CAD).
3. Далее на сцену выходит загрузчик - плагин AutoCAD, непосредственная автозагрузка которого происходит за счёт его регистрации в реестре. Автозагрузчик считывает ту информацию, которую юзер сформировал в предыдущем пункте и выполняет последовательную загрузку плагинов.
4. Будет иметься ещё одно внешнее exe приложение, в котором, с помощью GUI, юзеру будет динамически формироваться справочная система, объединяющая в себе справку всех плагинов, выполненных в соответствии с шаблоном. Приложение будет предоставлять пользователю и полный перечень имеющихся ключевых слов, собранных из всех плагинов. Т.о. поиск нужного контента будет осуществляться сразу во всех плагинах, построенных на основе шаблона.
5. Структура шаблона строилась сразу с заделом на то, что у программиста может возникнуть желание разместить свой плагин в магазин Autodesk. Для этого я вынес локализацию в отдельный каталог, чтобы добавлять новые локализации было очень просто.

Надеюсь, что ясно выразил свою идею.

Сообщение от Salt Сообщение от gomer Идея не нова, на лиспе такое было написано за царя гороха еще Речь идет о конкретном загрузчике от hwd, концептуально увязянном с тем, что описано в данной ветке.

gomer всё прекрасно понимает, просто очень любит "включать дурачка" с целью споров ни о чём. поэтому лично я не воспринимаю его всерьёз.

[Дима_]

Сообщение от 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. Переменные не нужны - имя функции это тоже переменная.

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

[Дима_]

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

[gomer]

Сообщение от hwd Тогда всё ещё проще.

Особо хитрые лисперы могут обходиться безо всяких там defun-ов, вам сионистам этого не понять
а загрузчик так вообще смешной получается

Код:

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

 (defun C:LISP ()
  (load (getstring "\nИмя подпрограммы: "))
)

[hwd]

Сообщение от Дима_ либо сто раз продублировать

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

Сообщение от Дима_ либо делать в КАЖДОЙ программе загрузчик с рекурсивным поиском по папкам автокада - ИХМО это еще хуже

Ума не приложу, где это может потребоваться, особенно с учётом того, что имеется findfile. Элементарный пример (код) в студию...

[Дима_]

Сообщение от hwd для ста приложений так и будет - это своего рода "плата" за независимость.

Только, если ВНЕЗАПНО, потребуется внести изменения в библиотечную функцию (для совместимости с х64, найденной ошибкой и пр.) - все сто надо как переделать создателю (а я не думаю что он это захочет делать), так обновить все администратору - собственно это и есть слабое звено твоего подхода "автономности плагинов".

[hwd]

Сообщение от Дима_ Только, если ВНЕЗАПНО, потребуется внести изменения в библиотечную функцию (для совместимости с х64, найденной ошибкой и пр.) - все сто надо как переделать создателю (а я не думаю что он это захочет делать), так обновить все администратору - собственно это и есть слабое звено твоего подхода "автономности плагинов".

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

мне всё же было бы интересно увидеть пример, соответствующий этой фразе:

либо делать в КАЖДОЙ программе загрузчик с рекурсивным поиском по папкам автокада - ИХМО это еще хуже

поскольку мне не удаётся представить такую ситуацию.

[Дима_]

не очень понял пример чего - программы которая не знает где ее библиотека?

[hwd]

Сообщение от Дима_ не очень понял пример чего - программы которая не знает где ее библиотека?

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

загрузчик с рекурсивным поиском по папкам автокада

?

[Дима_]

Сообщение от hwd если программа не знает где её библиотека - значит это не программа, а мусор.

Нет это значит, что Вы совсем не знакомы с автолиспом - ибо практически все лисп программы использующие библиотеки считают, что последние уже загруженны (то есть если она запущенна - значит установленна, соответственно вместе с библиотеками). А потребоваться он может - как раз если Вы хотите копировать лисп файл без установки бог весть куда и запускать его (он же не знает откуда вы его запустили, соответственно и не знает где он лежит).
з.ы. более того лисп программа может быть и не загруженна, а сгенерированна другой программой...
з.з.ы у лиспа мусором считаются как раз программы которые знают, где их библиотеки (ну или dcl описание) - где нибудь в c:\super_proga\...

[gomer]

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

[hwd]

Сообщение от Дима_ Нет это значит, что Вы совсем не знакомы с автолиспом

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

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

Сама по себе программа ничего не предполагает (считает) - это предположение программиста, пишущего код. И это его предположение - одна из наиболее часто встречающихся у LISP программистов грубейших ошибок.

Сообщение от Дима_ то есть если она запущенна - значит установленна, соответственно вместе с библиотеками

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

"Установлено" не то же самое что "Загружено". Разницу чувствуешь? Что (кроме лени) мешает программисту, прежде чем начать грузить лисп, выполнить предварительную проверку, мол а надо ли его грузить? Может он уже загружен др. лисп-программой? Зачем повторно грузить то, что уже загружено, выжирая тем самым оперативную память, которую автокад и так безжалостно расходует?

А потребоваться он может - как раз если Вы хотите копировать лисп файл без установки бог весть куда и запускать его (он же не знает откуда вы его запустили, соответственно и не знает где он лежит).

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

он же не знает откуда вы его запустили, соответственно и не знает где он лежит

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

з.з.ы у лиспа мусором считаются как раз программы которые знают, где их библиотеки (ну или dcl описание) - где нибудь в c:\super_proga\...

программы, которые знают где искать свои ресурсы - работают. Программы, которые понятия не имеют, где искать свои ресурсы - не работают. Так что из этого можно отнести к категории "мусор"? Вопрос риторический.

c:\super_proga\

открой для себя использование системных переменных.

[gomer]

Сообщение от hwd открой для себя использование системных переменных.

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

[hwd]

Сообщение от gomer программа привязанная к системной переменной запросто откажется работать в другом месте, это не выход

без комментариев...

[Дима_]

Сообщение от hwd Даже моих скромных познаний в лиспе хватает на то...

ну давай посмторим

Что (кроме лени) мешает программисту, прежде чем начать грузить лисп, выполнить предварительную проверку, мол а надо ли его грузить? Может он уже загружен др. лисп-программой?

по вышеизложенным причинам лисп программы НЕ ГРУЗЯТ (load ...) свои библиотеки - другая структура у лисп программ

Зачем повторно грузить то, что уже загружено, выжирая тем самым оперативную память

можешь хоть 100000 раз грузить одну и ту же программу - работать будет только последняя копия - остальное будет в памяти до первого вызова сборщика мусора

А не нужно "копировать лисп файл без установки бог весть куда и запускать его" - я именно для этого шаблон и написал

только вот уже написанные программы об этом шаблоне ничего не знают

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

еще раз - не "грузят они другие лисп файлы" - вначале библиотеки - потом функции их использующие

Но, тем не менее, если лисп будет лежать в шаблоне, то он с лёгкостью сможет узнать каталог своего размещения.

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

программы, которые знают где искать свои ресурсы - работают

хорошие лисп программы свои ресурсы создают сами - да да - такой подход является именно хорошим тоном для лиспа.

открой для себя использование системных переменных

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


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

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

[gomer]

Сообщение от Дима_ только тем самым поиском

и совсем не факт, что это сработает, яркий тому пример программы прокат и болты от культового автора, которые работать вместе не умеют

[Boxa]

Я так понимаю, что шаблон в первую очередь создавался под DLL и ARX приложения, для них, все что описано в шаблоне, вполне корректно и замечаний не вызывает. Может стоит повременить пока с добавлением в шаблон Lisp программ и посмотреть как это все заработает с dll?

[hwd]

Сообщение от Boxa Я так понимаю, что шаблон в первую очередь создавался под DLL и ARX приложения, для них, все что описано в шаблоне, вполне корректно и замечаний не вызывает. Может стоит повременить пока с добавлением в шаблон Lisp программ и посмотреть как это все заработает с dll?

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

[Do$]

Это, как раз-таки, больше всего интересует! Я имею в виду как будут выглядеть вписанные в этот шаблон лиспы.

[hwd]

Сообщение от Do$ Это, как раз-таки, больше всего интересует! Я имею в виду как будут выглядеть вписанные в этот шаблон лиспы.

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

[Do$]

Сообщение от hwd в таблицу загрузок добавил несколько записей

Это просто таблица в хелп-файле?

[hwd]

Сообщение от Do$ Это просто таблица в хелп-файле?

что подразумевается под "просто таблицей"? что мешает кликнуть мышью на странице и из контекстного меню выбрать пункт "посмотреть исходный код страницы"?

[hwd]

На основе того, что описывалось выше создана динамически формируемая справочная система (отдельное exe-приложение), которая выглядит следующим образом:



Логика такая: каталогов с плагинами (на скрине показан только один - "Песочница") может быть сколько угодно (на усмотрение администратора CAD). Например - в одном размещается то, что относится к нормоконтролю и стандарту предприятия, а в другом - дополнительные утилиты, полезные в работе. В GUI каждый такой каталог отображает вместо своего имени "человеческое" (например "Песочница" - это на самом деле каталог "sandbox"), понятное пользователю. Все плагины группируются по их авторам (инфа считывается из соответствующих XML-файлов и подставляется в нужных местах в GUI).

Те плагины, напротив которых юзер устанавливает галочки, будут автоматом загружаться в автокад (если под запущенную версию автокада имеется соответствующая версия плагина). На скрине видно, что одна из галочек включена и заблокирована - значит этот плагин установлен администратором CAD в автозагрузку для некоторой доменной группы, в состав которой входит текущий юзер). На основе снятия/установки галочек формируется XML-файл, содержащий в себе инфу о том, что следует грузить в автокад. Этой инфой пользуется загрузчик. Загрузчик сам определит нужно ли добавлять в Support Search Path какие-либо каталоги (если нужно - добавит их), а так же определит, нужно ли выполнять загрузку приложения, или же оно уже зарегистрировано в реестре с этой целью. Вся инфа считывается из соответствующих XML-файлов оболочек плагинов.

При выборе в древовидной структуре интересующего плагина, в правом контроле (WebBrowser) отображается содержимое файла readme.html выбранного плагина. Если в каталог плагинов добавить новый плагин - он автоматом появится в динамически формируемой справочной системе. Ну и, конечно же присутствует поиск по ключевым словам, который выполняется по всем доступным плагинам...

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

[Дима_]

Сообщение от hwd если под запущенную версию автокада имеется соответствующая версия плагина

Все последующее - мысли вслух:
Скажу честно, я хоть и сам делал "установщики" плагинов используя данный алгоритм (установка под "запущенную версию"), но все-же данный метод ИХМО "кривоват" и скажем так для ленивых, (особенно, для Вашего проекта - так сказать "с претензией"), если настройка под запущенную версию, то она и должна запускаться непосредственно изнутри (перекомпилировать и собрать в твой-же сверток помеченный администратором + setup'ка для автозапуска, либо (startapp exe)) - в общем не суть, как реализовать. А если "отдельный exe" (что в общем правильно) - то типо выбрать все доступные версии (с предупреждением, если для некоторых нет плагинов), либо поддерево галочек из установленных&доступных в "свертке" версий автокада. Ведь это-же не инсталяшка 1-го плагина - а целая "система".
p.s. А в общем весьма красиво.

[hwd]

Сообщение от Дима_ все-же данный метод ИХМО "кривоват"

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

Сообщение от Дима_ если настройка под запущенную версию, то она и должна запускаться непосредственно изнутри (перекомпилировать и собрать в твой-же сверток помеченный администратором + setup'ка для автозапуска, либо (startapp exe)) - в общем не суть, как реализовать.

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

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

выборка доступных версий - это лишние, не нужные телодвижения. сегодня доступны одни версии, завтра другие. Наличие галочек указывает на изъявление желения о подгрузке. Если под нужную версию автокада нет откомпилированной сборки - загрузка производиться не будет, но если со временем она появится - за счёт наличия галочки этот плагин автоматом попадёт в автозагрузку. Юзер прекрасно понимает, будет ли плагин грузиться в тот или иной автокад, поскольку в readme.html перечислены все системные требования, для которых плагин сможет работать.

Сообщение от Дима_ Ведь это-же не инсталяшка 1-го плагина - а целая "система".

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

[hwd]

Внёс ряд изменений в состав шаблона и показанных выше примеров (обновлять ссылки пока не стал, т.к. возможно ещё что-нить изменю):

1. Убрал из обёртки информацию о доменных группах, которым грузится плагин (об этом уже писал выше). Эта информация теперь хранится в одном общем файле, чтобы с ней было удобней работать администратору CAD.
2. Добавил в оглавление новую страницу - "Программирование", в которой разработчикам размещается информация о vba и lisp-функциях (не путать с пользовательскими командами), предоставляемых библиотекой. Блок содержит полную информацию о каждой функции, с детальным описанием её назначения, а так же всех её параметров и результата работы. Помимо этого каждое описание функции содержит произвольное количество примеров, демонстрирующих работу функции с подробными примечаниями. Так же каждой функции имеется блок информации, предназначенный для размещения в нём произвольного количества важных примечаний, касающихся работы функции. С каждой функцией ассоциируется произвольное количество ключевых слов, как это сделано для команд, чтобы в динамической справке (скрин показан выше в топике) можно было искать не только команды, но и функции.
3. Помимо информации, относящейся непосредственно к функциям, имеется блок произвольных примеров, написанных на LISP, VBA, ObjectARX и .NET (на усмотрение разработчика).
4. Добавил возможность назначения ключевых слов плагину в целом. Это сделано для того, чтобы по ключевым словам можно было искать такие плагины, которые не содержат лисп-функций и команд, а работают в фоновом режиме (например программы нормоконтроля).
5. Добавил блок, сообщающий о наличии файлов меню доступных для плагина, их описании и расположении (рекомендуется хранить в ./settings).

[hwd]

Релиз-кандидат. Пара скринов:

Первый


Второй


Ну и, на YouTube видео по теме, т.к. скринами много не покажешь: http://www.youtube.com/watch?v=M8Mk9VHC9Yc

[Дима_]

Красиво ничего не скажешь, поясни пож. еще разок (я чуток уплыл по теме), твоя гуишка настраивает конфигурационный файл для твоего "основного корпаративного загрузчика", или вносит изменения напрямую в автозагрузку соответствующего автокада? (ну и если второе - то выкладывай что-ли).
Offtop: Прошу прощения за брюзжание, но всплывающие окошко со списком всех версий, это ИХМО совсем не айс, ну добавляй "нерабочие" как ReadOnly флажки в конец каждой ветки (с пунктом в контекстном меню - типо показывать все/рабочие или крыжиком), ну или еще как - а то это окошко смотриться как инородное тело (да и пункт в котором может не оказаться ни одной версии под установленные акады - тоже как-то не очень будет гармонировать).
p.s. про то что настраиваеться увидел на видео - жаль что не самостоятельная - но оно понятно.
p.p.s. просмотрев видео ВДРУГ понял, что совсем не учтено (системно так сказать) возможные отличия функционала в плагинах под различные версии (кроме как написать все в кучу или в доп. информацию по версии) - хотя это конечно не "большая беда" но продумать явно стоит.

[hwd]

Сообщение от Дима_ твоя гуишка настраивает конфигурационный файл для твоего "основного корпаративного загрузчика", или вносит изменения напрямую в автозагрузку соответствующего автокада?

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

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

Это не всплывающее окошко, а модальное окно, вызванное из контекстного меню плагина. Если отображать всё, как ты предлагаешь, используя ReadOnly для отсутствующих версий, то иерархия существенно разрастается за счёт лишней информации. Юзер хочет видеть то, что может применить на своей машине. Если он захочет узнать о полном перечне доступных версий - вызовет соответствующий пункт контекстного меню и посмотрит информацию, которая будет показана ему в "инородном теле"(с). Изначально я отображал все версии, но затем отказался от этой идеи - текущий вариант мне нравится больше.

Сообщение от Дима_ p.s. про то что настраиваеться увидел на видео - жаль что не самостоятельная - но оно понятно.

Не понял, это ты о чём?

Сообщение от Дима_ p.p.s. просмотрев видео ВДРУГ понял, что совсем не учтено (системно так сказать) возможные отличия функционала в плагинах под различные версии (кроме как написать все в кучу или в доп. информацию по версии) - хотя это конечно не "большая беда" но продумать явно стоит.

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

п.с. шаблон, документацию и примеры в первом посте я пока не обновляю, т.к. документацию ещё не подкорректировал.

[Дима_]

Сообщение от hwd Не понял, это ты о чём?

Про первый вопрос - что настройки применяються не сразу а меняется конфиг загрузчика.

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

все верно - просто упускаеться момент что НОВЫЙ плагин может иметь частично ограниченный функционал для СТАРЫХ версий автокада - то есть используеться например аннатотивность или параметризация - понятное дело что она может быть не во всех версиях - но это мелочи - и для учета всего загрузчик действительно "разрастется".

[hwd]

Сообщение от Дима_ Про первый вопрос - что настройки применяються не сразу а меняется конфиг загрузчика.

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

Сообщение от Дима_ все верно - просто упускаеться момент что НОВЫЙ плагин может иметь частично ограниченный функционал для СТАРЫХ версий автокада - то есть используеться например аннатотивность или параметризация - понятное дело что она может быть не во всех версиях - но это мелочи - и для учета всего загрузчик действительно "разрастется".

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

[Boxa]

ИМХО, все баги, неудобства и излишества всплывут при тестирование как пользователями, так и разработчиками.
Пока же все выглядит здорово.

[hwd]

Сообщение от Boxa ИМХО, все баги, неудобства и излишества всплывут при тестирование как пользователями, так и разработчиками. Пока же все выглядит здорово.

Пользователям (на которых тестировал) понравилось - с их стороны претензий не было... Доделываю .Net API.