I resolved my problem by dropping the parameter approach. In component A I now have a property in which component B is injected. This allows me to call the processing logic in component B directly from the pageBeginRender method of component A which guaranties that the list is available: getComponentB().processList(list);
On 10/7/05, Markus Joschko <[EMAIL PROTECTED]> wrote: > I had a look through the mailinglist (I know I should have done this > before posting) and the recommended approach was to use a synthetic > property. For me this means that this is a custom method that is > called instead of letting tapestry generate the property. But this > seems no longer be possible in tapestry 4.0 according to a comment in > the ParameterPropertyWorker: > > // 3.0 would allow connected parameter properties to be fully > implemented > // in the component class. This is not supported in 4.0 and an > existing > // property will be overwritten in the subclass. > > Does that mean that the workaround is also no longer possible? > > markus > > > On 10/7/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > > Markus Joschko escribió: > > > > >Nope. Does not work as the pageBeginRender methods of the components > > >are not called in a specific order (see the gotchas section on the > > >WIKI). In fact the pageBeginRender method of component B is called > > >before the pageBeginRender method of component A which means that the > > >list property of component B is not yet set by component A. > > > > > >It seems to me that I use the framework fundamentaly wrong in this > > >case. But I can't see a possibility how to solve this problem properly > > >with tapestry. > > > > > > > > Couldn't Tapestry guarantee a specific order for pageBeginRender execution ? > > > > Right now I'm using a workaround... just using my own "nestedInitialize" > > interface and recursively calling down components in order, so I can > > initialize them correctly.. but I guess this is something we'd expect > > from the framework. > > > > >markus > > > > > >On 10/6/05, Peter Ertl <[EMAIL PROTECTED]> wrote: > > > > > > > > >>try the 'begin page render' event > > >> > > >>it's after properties have been set up, still modifiable, > > >>and just before rendering of the components start > > >> > > >>in T4: > > >> > > >>implement PageBeginRenderListener in your page > > >> > > >>in T3: > > >> > > >>implement PageRenderListener in your page > > >> > > >> > > >> > > >> > > >> > > >>>--- Ursprüngliche Nachricht --- > > >>>Von: Markus Joschko <[EMAIL PROTECTED]> > > >>>An: [email protected] > > >>>Betreff: Where should a property be processed .. > > >>>Datum: Thu, 6 Oct 2005 17:22:20 +0200 > > >>> > > >>>Hi list, > > >>>maybe you can help me with a "property" problem. > > >>>I have a parent component A which fetches a lot of information from a > > >>>webservice in its prepareForRender method. One part of the > > >>>information is a list which should be passed as a parameter to > > >>>component B which is nested inside of component A. > > >>>This is easy, now for the problematic part: component B processes the > > >>>list and stores some of the values in a persistant property. At least > > >>>that is the plan. > > >>>I have troubles finding the right place to process this list. Doing > > >>>this in the renderComponent method of component B fails, because it is > > >>>not allowed to modify persistant properties during render. Using the > > >>>pageBeginRender method of component B also fails because there is no > > >>>specific order in which the pageBeginRender methods are called and > > >>>therefore component B can be called before component A and the > > >>>parameter which should hold the list is empty. > > >>> > > >>>Is there a workaround? I could for sure process the list in component > > >>>A instead of component B but this moves logic into component A which > > >>>simply does not belong there. Or I could do a second webservice > > >>>request in component B to retrieve the list in its pageBeginRender. > > >>>But then I have two remote hits which I really want to avoid. > > >>> > > >>>Any ideas? > > >>>Thanks, > > >>> Markus > > >>> > > >>>--------------------------------------------------------------------- > > >>>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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
