Hi Mark,
Thanks so much for replying.....
You've given me some great hints I think -- Re: Engine & Services. Would you be kind enough to forward some code snippets ?
I too am focusing now on the Visit object -- but not with as much success as you.
I think I need to go back to the documentation -- I'm missing some fundamental Tapestry concept.
Our scenario is complicated through the use of Frame/Frameset I think ?
Becuase the Frame component can only reference "Page" components -- and not something more abstract up the same component tree -- it adds another level of indirection....
I've played with (at the component level)...
1) getContainer.getPage.getContainer.getComponent("x") like API
2) Using a hashtable in the Visit object -- to store "this"/references to components.
Each component populates the Visit-hashtable in their:
finishLoad(IRequestCycle, IPageLoader, IComponentSpecification) {
aVisit.getAComponentMap().put("myComonent",this);
}
In both cases it feels very ugly/kludgy..... like I'm not using the framework correctly ?
I thought I read somewhere that getComponent("x") like API should be able to resolve any component at/under the "Application" level..... but I'm finding that it can ONLY see components at the "Page" level ?
I think I need to review the Tapestry "Cycle/Page" lifeCycle again ?
Sometimes the Visit object is there.... sometimes it's not. Sometimes you can set a property, sometimes you can't -- and even then -- if you do succeed the component has already rendered and does not see the new value ?
In any case -- I think your code snippets would be very helpfull ....
Hope you can post some more clues -- in particular your use of the Engine/PersistenceServices/Caching APIs
Hope to hear from you....
Thanks
Frank
From: Mark Dillon <[EMAIL PROTECTED]> Reply-To: Mark Dillon <[EMAIL PROTECTED]> To: Tapestry users <[email protected]> Subject: Re: Passing data, object between components... Date: Mon, 16 May 2005 12:53:00 -0700
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
