Описание.

Каждый плагин имеет свою бизнес  логику(контроллер) , свое представление - вью , и свою модель данных.
Плагины независимы друг от друга. 
При обращении к плагину : вываливается вью этого плагина, пользователь вводит какие то данные и сабмитит 
(возможен авто сабмит: ajax) , данные обрабатывает контроллер и вываливает на следующую (эту) вью результат (в общем стандартный mvc).
И так для каждого плагина. (разные вью, разные контроллеры).

Вопросы.

Сначала думал делать это с помощью jsf , но у каждого плагина будут свой managed-beans , которые мне надо будет в он-лайн режиме регистрировать в faces-config.xml, да и не только их ... не представляю как это сделать.

Делать это с помощью сервлетов/jsp? Аналогичная проблема: серлеты надо регистрировать в web.xml ... тоже, пока не представляю как это сделать.

Всю логику выносить на вью - только jsp .... фу ... так я делать не буду.

Возможно существуют какие то фрэймворки для таких задач ?? Посмотрел на JPF - хорошая штука, но не вэб ориентирована ...

У кого какие есть идеи!?

Добавлено через 6 минут и 14 секунд
хм..получается свой ... менеджер приложений.

Возможно стоит использовать SpringFramework
А для динамического добавления модулей использовать механизм фабрик Spring.
У меня когда-то даже получалось на базе этого построить прототип, но очень много пришлось писать своего кода:(
p/s
Также можно обратить внимание на технологию OSGi  и ее реализации, например эту. Технология OSGi  используется для построения Eclipse IDE.

Это сообщение отредактировал(а) intr - 17.6.2008, 04:11

плохо знаю Spring, но разве там не надо регистрировать каждый контроллер в config файле?
хотелось бы узнать поподробней про механизм фабрик в Spring.

Это сообщение отредактировал(а) v2v - 17.6.2008, 08:44

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

Значит надо читать документацию - http://static.springframework.org/spring/d...ence/beans.html 

действительно из этого что то может получиться.


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

Тогда, может быть, нужны не плагины, а отдельные веб приложения и каждое представлено своим war.    

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






Это сообщение отредактировал(а) COVD - 17.6.2008, 15:42

поясню на пальцах ...
назовём моё приложение ПОСУДА.
Каждый прибор имеет ряд стандартных действий: у него добавляют пищу, с него едят, его моют.
Действия однотипные но для каждого прибора выполняются по своему, в стакан чай наливаем а вот гречку в тарелку уже не нальёшь ..
Аналогично с мытьём и процессом приёма пищи - для каждого прибора свой: действия разные но однотипные ..

Вы же предлагаете каждый прибор обслужитвать по своему: для каждой тарелки своя счётка для мытья, своя подставка на столе и тд

надеюсь ясно выразился

Или такое лучше реализовывать не на основе плагинов?? (я думаю всё таки плагины...если покупаем новую тарелку не надо делать новую  полку для посуды а просто добавляем её на свободное место существующей)


вы правы это важно но не думаю что это ключевой момент/ как по мне ключ - это возможность внести новую фичу без переинсталяции системы с 0

Это сообщение отредактировал(а) v2v - 17.6.2008, 18:10

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

Поднимаю тему,
Необходимо создать web-приложение, пользователи которого могли бы расширять функционал путем подключения плагинов. У всех пользователей есть набор одинаковых плагинов, которым управляет администратор, у каждого пользователя - набор личных плагинов (дополнительно).
Что появилось за 2 года ? Есть ли примеры (код, дизайн) таких приложений ?
Спасибо.

Покопавшись, я понял, что можно довольно просто реализовать расширяемое web-приложение с использованием Java Scripting технологии и Java-движка, который можно взять здесь.
Причем, можно как интерпретировать код, так и исполнять, предварительно скомпилировав его в байт-код. Таким образом расширения пользователей могут быть написаны на каком угодно языке, главное чтобы они могли быть преобразованы в байт-код.
Остается только проблема с безопасностью, я ещё не разбирался, можно ли полностью контролировать, что можно делать, а что нельзя в контексте исполнения кода пользователя.
OSGi - это слишком громоздко.

Это сообщение отредактировал(а) En_t_end - 30.3.2011, 20:16

Для Томката любое web-приложение уже является плагином. Томкат - контейнер плагинов. Потому, что положили  war  в webapps - задеплоен, удалили - андеплоен. Чего еще желать? OSGi контейнер не нужен. Его роль выполнит Томкат. Почему бы не расширять функционал путем добавления новых "web-приложений" ?  Это SOA. A OSGi реализует идею SOA внутри одного приложения. И для десктоп приложений это единственный вариант. Но для клиент-сервер доступна нормальная SOA. 

Это сообщение отредактировал(а) COVD - 31.3.2011, 16:40

И что, любой пользователь сможет деплоить приложения ко мне на сервер ? Нежизнеспособно, ИМХО. 
Быть может не совсем понятно о каких плагинах идет речь. К примеру, у вас есть веб-ориентированный текстовый редактор и хотелось бы предоставить пользователям возможность расширять его функционал путем добавления пакета классов, использующих открытое API, для обращения к основным функциям редактора. Тогда типично пользователь аплоадит jar через специальный сервис веб-приложения, далее специальный движок плагинов подгружает по мере надобности классы из этого jar и вызывает определенные методы.

Веб приложения не обязаны лежать на одном сервере. В частности, на вашем. Клиенту позволено слать запросы куда угодно. Расширение функционала путем добавления сервисов.

Это сообщение отредактировал(а) COVD - 6.4.2011, 14:08

Ок, я понял вашу позицию, но мне это совершенно не подходит.

Не спора ради, а просто размышляю.

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

Далее, хочется "расширять функционал" и этот новый функционал хочется реализовывать, вызывая новые методы в новых классах на сервере. Значит клиент должен послать новый запрос, который указывает на новый функционал. Наверное, это новый параметр запроса. Но ведь с таким же успехом это может быть и новый адрес запроса !  

Есть упрощенное представление, что "клиентов много - сервер один". Но серверов тоже может быть много. Хотя для каких-то задач это, наверное, избыточно, неоправдано дорого. В данный момент. А завтра? Все эти "облака", grid computers - это движение в сторону распределенных серверных систем.   

Это сообщение отредактировал(а) COVD - 7.4.2011, 04:50