See intermixed. On 3/17/06, Marcio E Miranda <[EMAIL PROTECTED]> 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
