May Shale aid in inter-component/bean communication and possibly extend that to inter-portlet communication?

[Marcio E Miranda <Ma...@fastsearch.com>]

This may be just a JSF question, but Shale may somehow aid in the
solution, so here it goes: 

 

-- Web App

 

Let's say that we have several instances of the following components in
a view:

 

Component A (Ca) is backed by bean A (Ba)

 

Component B (Cb) is backed by bean B (Bb)

 

Component C (Cc) is backed by bean C (Bc)

 

Besides that, the following relationship exists between the components
(and beans indirectly):

 

Ca  (1x N)  Cb  (1 x N) Cc.

 

So, when some action (or event) is executed on an instance of Ca, I
would like all instances of Bb associated with the instance of Ca that
triggered the event, to have some method executed.

The execution of the method in Bb would also trigger the execution of
another method in all instances of Bc associated with the instance of Bb
that has just been executed.

 

To give a more concrete example, say that component A is a search box
component, component B is a search result component, and component C is
a component that would should some aspects of a search result, like
statistics. My view could have one instance of the search box component,
two or more instances of the search result component, each one searching
a different search domain (like internet and intranet), and I could have
one or more "statistics" component associated with each search result
component. When the user submits a new search, both search results must
be notified and execute the search, which in turn would trigger an event
in the statistical component, which would use the search result to
gather its data. 

 

What's the best technique to implement that in JSF? Would Shale provide
any mechanism to make that easier to accomplish? 

 

-- Portlets

 

Now, let us assume that I want to deploy the above scenario in a portlet
environment, so that:

 

Portlet A has Component A   

Portlet B has Component B

Portlet C has Component C.

 

The portal administrator may add or remove the portlets at any time and
I can have several instances of each portlet, and somehow I must keep
the relationship described in the previous example.

 

So, now I want the portlets to communicate with each other, like I
wanted components and backing beans to communicate in the previous
example. Since the JSR 168 doesn't provide inter-portlet communication,
maybe JSF (or Shale) could help in providing such mechanism, through
components.

 

Could I use in this case the same mechanism developed in the previous
example, given the fact that the portlet lifecycle may be dynamic?

 

Best regards,

Marcio

 

 

Re: May Shale aid in inter-component/bean communication and possibly extend that to inter-portlet communication?

[Craig McClanahan <cr...@apache.org>]

See intermixed.

On 3/17/06, Marcio E Miranda <Ma...@fastsearch.com> wrote:
>
> This may be just a JSF question, but Shale may somehow aid in the
> solution, so here it goes:
>
>
>
> -- Web App
>
>
>
> Let's say that we have several instances of the following components in
> a view:
>
>
>
> Component A (Ca) is backed by bean A (Ba)
>
>
>
> Component B (Cb) is backed by bean B (Bb)
>
>
>
> Component C (Cc) is backed by bean C (Bc)
>
>
>
> Besides that, the following relationship exists between the components
> (and beans indirectly):
>
>
>
> Ca  (1x N)  Cb  (1 x N) Cc.
>
>
>
> So, when some action (or event) is executed on an instance of Ca, I
> would like all instances of Bb associated with the instance of Ca that
> triggered the event, to have some method executed.
>
> The execution of the method in Bb would also trigger the execution of
> another method in all instances of Bc associated with the instance of Bb
> that has just been executed.
>
>
>
> To give a more concrete example, say that component A is a search box
> component, component B is a search result component, and component C is
> a component that would should some aspects of a search result, like
> statistics. My view could have one instance of the search box component,
> two or more instances of the search result component, each one searching
> a different search domain (like internet and intranet), and I could have
> one or more "statistics" component associated with each search result
> component. When the user submits a new search, both search results must
> be notified and execute the search, which in turn would trigger an event
> in the statistical component, which would use the search result to
> gather its data.
>
>
>
> What's the best technique to implement that in JSF? Would Shale provide
> any mechanism to make that easier to accomplish?


Shale doesn't have anything that would address this need.  But it sounds to
me like an event-based solution is what you would need.  Make the search
component fire an event, and make the other components interested in what is
happening register themselves as listeners for that event.

-- Portlets
>
>
>
> Now, let us assume that I want to deploy the above scenario in a portlet
> environment, so that:
>
>
>
> Portlet A has Component A
>
> Portlet B has Component B
>
> Portlet C has Component C.
>
>
>
> The portal administrator may add or remove the portlets at any time and
> I can have several instances of each portlet, and somehow I must keep
> the relationship described in the previous example.
>
>
>
> So, now I want the portlets to communicate with each other, like I
> wanted components and backing beans to communicate in the previous
> example. Since the JSR 168 doesn't provide inter-portlet communication,
> maybe JSF (or Shale) could help in providing such mechanism, through
> components.
>
>
>
> Could I use in this case the same mechanism developed in the previous
> example, given the fact that the portlet lifecycle may be dynamic?


JSF events are not going to help you here, because they all operate within
the context of a single request.  In a portlet world, only one of the
portlets will perform the "processAction" part of the portlet lifecycle (in
your use case described above, presumably this would be the portlet
containing the search widget).  Then, all three portlets will be asked to
rerender themselves.

Therefore, you will have to use a different solution in this scenario.  If
all three portlets are deployed in the same WAR file, then you can use
portlet sessions to share information.  If they are deployed in different
WAR files, then even that will not help and you'll need to use some database
or message based mechanism to communicate.

Best regards,
>
> Marcio


Craig