I'm doing something similar to what you're doing. I have a frames based application that has a slightly modified version of the tacos:Tree component in the left frame. Clicking on a Node or Folder in the left calls an activate() listener with a custom URI as a service parameter. In my case, this URI consists of the fully qualified class name and an identifier (ie. 'com.mycompany.myproject.model.MyClass:765'). The activate listener method places this URI on the Visit, and refreshes the frameset. The right frame looks for a URI in the visit and, if one is found, it grabs the object from the persistence service (usually from the cache), and displays it accordingly.
That's the way I'm doing it for now. That said, I'm not terribly happy with the fact that I have to use the Visit. I've been thinking about scrapping the frameset and moving to a more AJAX like approach, so I haven't put a ton of thought into a better solution. I would, however, like to hear what others are doing in this sort of situation. Thanks, Mark On 5/13/05, Frank Misa <[EMAIL PROTECTED]> wrote: > Hi All, > > Hoping someone here can clarify for me what best practice is for > inter-component communication ? > > I have a typical frameset page -- with contrib:TreeView as navigator on left > and two custom components on the right, stacked on top of eachother. I > want to update the two components in the right frames with information based > on the node/folder the user selects on the left frame. > > Should I be using: > 1) The common "Visit" object to share this information ? Any better way > to share session data ? > 2) Try to share a common "model" between all three components ? Any > examples of how I can > control instantiation of the model and make sure each component is > sharing the same instance ? > 3) Somehow pass references (as parameters ?) of the two right component's > models to the > left TreeView's TreeStateListener object ? And have the > TreeStateListener update the others > 4) Any other better ways to manage this ? I know this must be a very > common requirement. > > Hope someone can help me flatten this Tapestry learning curve a little. I'd > very much appreciate a short example or link to existing components that do > similar things.... > > Thanks > Frank > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
