[news.eclipse.newcomer] Re: Suitable architecture for a plugin project

["Walter Harley" <eclipse@xxxxxxxxxxxxxx>]

"buddhika chamith" <chamibuddhika@xxxxxxxxx> wrote in message 
news:269bfcf75fd50441dc165e06c6cd318c$1@xxxxxxxxxxxxxxxxxx
> 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%93controller .

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).