[ANN] Tabax 0.1 -- панель задач для Axapta

[belugin]

Есть идея добавить в табакс плагины. Примерные наброски здесь:
*http://erpkb.com/Axapta/Tabax/Plaginy

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

[oip]

Цитата:

Сообщение от belugin

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

Вполне бегло работает на не самом быстром ноуте.

Первый запуск ~1 секунда. Второй и последующие - почти мгновенно.

[gl00mie]

Цитата:

Сообщение от belugin

Есть идея добавить в табакс плагины. У кого какие мысли по этому поводу?

Цитата:

Плагин — это класс, у которого есть свойство Tabax и название которого начинается на TabaxPlugin_

По-моему, неплохой пример реализации «плагинов» можно найти в проверке целостности данных (класс SysConsistencyCheckJob и соотв. форма). Там эти самые «плагины» выбираются из AOT не по префиксу названия класса, что все же как-то кривовато , а по наследованию от класса SysConsistencyCheck, заодно в этом классе определяется и интерфейс для плагинов, и вспомогательные функции, которые плагины могут использовать, наподобие метода SysConsistencyCheck.kernelCheckTable().

[kashperuk]

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

Цитата:

Сообщение от belugin

Требования
Tabax должен состоянть из одной формы и больше из ничего

Взято из: http://erpkb.com/Axapta/Tabax/Plaginy

[gl00mie]

Цитата:

Сообщение от kashperuk

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

Не вижу объективных причин для столь жесткого условия в контексте прикручивания к Табаксу плагинов. Когда он был сам по себе, то пожалуйста, можно весь код, вопреки best practices, пихать в методы формы, но когда появляются плагины и объективная необходимость как-то формализовать взаимодействие с ними, то без какого-то развитого интерфейса взаимодействия уже не обойтись. Идентификация плагина по префиксу названия класса - это мелочи, самое интересное начнется тогда, когда понадобится как-то регулировать работу Табакса с плагинами, работу плагинов с Табаксом и работу плагинов в окружении других плагинов (какие-нить блокировки и т.п.). Как только дело дойдет до реальной работы, передача плагину ссыли на экземпляр формы уже никого не устроит. Пусть Табакс предполагает наличие у класса-плагина метода void tabax(FormRun _fr), но как плагин будет взаимодействовать с самим Табаксом? тоже предположит, что у формы есть какие-то методы с определенными наборами параметров? А в следующей версии Табакса они сохранятся, а новые добавятся? А как плагин сможет проверить, что он работает как минимум с такой-то версией Табакса, реализующей нужную ему функицональность?..
Imho по-любому дожен быть 1) формализованный интерфейс для плагина с поддержкой версионности; 2) формализованный интерфейс для Табакса и его сервисных функций, предоставляемых плагину, с поддержкой версионности. Посмотрите на Far Manager plugin API, посмотрите на Winamp plugin API, посмотрите на COM-интерфейсы, в конце концов...

[belugin]

Цитата:

Сообщение от gl00mie

[FONT="Trebuchet MS"]Когда он был сам по себе, то пожалуйста, можно весь код, вопреки best practices, пихать в методы формы, но когда появляются плагины и объективная необходимость как-то формализовать взаимодействие с ними

Я бы заменил слово "необходимость" на слово "возможность".

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

Я в курсе насчет плагинов в фаре, эклипсе, Trac и ...

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

[gl00mie]

Цитата:

Сообщение от belugin

Я бы заменил слово "необходимость" на слово "возможность".

И это пишет человек, говоривший мне об абстрактных классах и интерфейсах!

Цитата:

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

Что значит «случайно испортить»? Взять форму от одной версии, а класс, реализующий логику работы или какой-то интерфейс (если предположить такое разделение), - от другой? Если человек может изменять объекты в AOT, то что мешает ему, к примеру, влезть в код формы и там что-нить «испортить»?..

Цитата:

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

Давайте поговорим об этом Какие такие ограничения и специфика области использования заставляют приделывать плагины.. непонятно как, не используя интерфейсы, проверку типов, возможности наследования, в нарушении best practices, сложившихся традиций и элементарных "правил хорошего тона" X++? Взять тот же Far Manager, передающий и принимающий в качестве интерфейсов таблицы указателей на функции, - там хоть какая-то типизация есть на уровне прототипов функций, описания структур, на основании чего можно еще при сборке плагина сделать элементарные проверки на уровне возможностей компилятора С. А тут, получается, не будет вообще никаких проверок до самого момента вызова, до того, как ядро не тыкнется в экземпляр объекта и, к примеру, не обнаружит отсутствие метода с именем "Tabax" или то, что переданная ссылка соответствует объекту совсем другого типа. Я уже не говорю про IntelliSense и прочие прелести жизни... Но зато Tabax будет занимать в AOT минимум визуального пространства! Конечно, это все перевешивает...