| Suitable architecture for a plugin project [message #269504] |
Wed, 18 March 2009 05:54  |
Eclipse User |
|
|
|
Hi,
I am not sure whether this is relevant to this group. Most probably it may
not be. I greatly appreciate if some one can point me to which newsgroup
this is more relevant because I was sort of redirected when I posted this
as a mail to WTP mailing list and now I am not sure to which newsgroup or
mailing list this is mostly related to.
I am trying to create a plugin for a process engine in which workflows can
be deployed . UI plugins which, upon some UI event will have to pull
information and manage life cycle events of the process engine(start/stop
etc). On the other hand the when specific events happen in the process
engine this has to be communicated with the respective UI plugins. I need
an architecture which decouples the process engine with the UI as possible
so it can be used with different UI or other non UI plugins which need to
use that process engine.
I was thinking of a suitable architecture for this scenario. I thought of
adding Listener extensions for the process engine plugin so any plugin
listening with these extensions will get the server events. But for UI to
process engine communication I could not think of a way which would push
information to and pull information from the process engine upon UI
events. I thought of importing process engine classes to the UI plugin to
do such communications but it will create some coupling between UI and the
server. Defining UI Listeners is not an option also for obvious reasons.
Can anybody help me with this design problem. I greatly appreciate any
suggetions.
Best Regards,
Buddhika
|
|
|
| Re: Suitable architecture for a plugin project [message #269526 is a reply to message #269504] |
Wed, 18 March 2009 11:38  |
| Eclipse User |
|
|
|
"buddhika chamith" <chamibuddhika@gmail.com> wrote in message
news:269bfcf75fd50441dc165e06c6cd318c$1@www.eclipse.org...
> Hi,
>
> I am not sure whether this is relevant to this group. Most probably it may
> not be. I greatly appreciate if some one can point me to which newsgroup
> this is more relevant because I was sort of redirected when I posted this
> as a mail to WTP mailing list and now I am not sure to which newsgroup or
> mailing list this is mostly related to.
>
> I am trying to create a plugin for a process engine in which workflows can
> be deployed . UI plugins which, upon some UI event will have to pull
> information and manage life cycle events of the process engine(start/stop
> etc). On the other hand the when specific events happen in the process
> engine this has to be communicated with the respective UI plugins. I need
> an architecture which decouples the process engine with the UI as possible
> so it can be used with different UI or other non UI plugins which need to
> use that process engine.
>
> I was thinking of a suitable architecture for this scenario. I thought of
> adding Listener extensions for the process engine plugin so any plugin
> listening with these extensions will get the server events. But for UI to
> process engine communication I could not think of a way which would push
> information to and pull information from the process engine upon UI
> events. I thought of importing process engine classes to the UI plugin to
> do such communications but it will create some coupling between UI and the
> server. Defining UI Listeners is not an option also for obvious reasons.
>
> Can anybody help me with this design problem. I greatly appreciate any
> suggetions.
I'm not sure what the "obvious reasons" are? Seems to me that this is a
fairly straightforward model/view distinction; the model (which contains no
UI) needs an API to permit viewing and modification, and the view needs to
register a listener on model deltas. One example of this within Eclipse is
the JDT UI and JDT Core packages.
You might further want to separate the controller aspect from the view.
There are examples and a good explanation of Model/View/Controller
architecture in Wikipedia,
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93cont roller .
You sound concerned about coupling between the view (the UI plugin) and the
model (the process engine). I'm not sure I see how you can view and modify
a model without the view knowing something about what it is viewing. The
important thing is to have the coupling be one-way only (view sees model
classes, not vice versa) and mediated through an API (view does not see
*implementation* classes from the model).
|
|
|
Powered by
FUDForum. Page generated in 0.07916 seconds
Home