cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Same component instance but multiple roles
Date Thu, 11 Jan 2007 19:29:26 GMT
Simon Stanlake napisaƂ(a):
> Hi,
> I think I have a simpler example that better illustrates the idea of 2
> roles 1 component instance. Think of a producer-consumer application. A
> producer component creates objects of type X. It then passes it to a
> component - call it the translator - for handling. The translator uses
> the X to create an object of type Y. A third component, the consumer,
> accesses the translator for objects of type Y when they are available.
> In this application, the translator plays 2 roles, the role of the input
> queue for newly formed X objects, and the role of the output queue for
> newly formed Y objects. Any component that produces X objects would
> access the translator using
> public void addX(X x)
> and any component that consumes Y objects would access it using
> public Y getY()
> These 2 roles should be separated into 2 interfaces, since they are
> really separate concerns. However, in the case that the collection of X
> objects and production of Y objects is accomplished inside one component
> instance, you would want to have 2 roles for the single instance.
> Something like...
> <snip/>
> Anyway, longwinded way of saying I want to do something like this...
> <role name="XStore,YProvider" default-class="Translator"/>
> Appreciate the response - it's nice to know people out there will take
> the time to help me out.
The question is what REALLY stops you of creating two components, one 
for storage and the second for translating and then one would pull the 
data from another? As you said, these two things are separate concerns 
so also should be implemented separately. I can imagine situation when 
number of objects stored in store grows and some persistence on 
filesystem/database is needed. Then, store component is just gateway to 
this media's and eventually caches some most frequently used objects. 
Don't you think separating this two concerns is good design practice?

Grzegorz Kossakowski

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message