I've tried everything I can think of. Opened a feature request on Tapestry:
https://issues.apache.org/jira/browse/TAPESTRY-2752 ownedthx wrote: > > Tried using a mixin on the zone returned. I wanted to see if I could just > return my component on BeforeRenderTemplate. I guess, though, that the > zone has to have my component defined (which however would cause the > recursion detection to fire), because I get an error on initial page load, > complaining that the zone does not define the component. > > At this point, I think this is a bug in Tapestry, because the recursion > detection logic shouldn't necessarily use what's in <t:block>. I > understand the whole reason it's there is to avoid infinite loops, but at > the same time I should be able to do this, since I'm not actually doing > recursion. It's like I want a: > > <t:block recursion="ignore"> > > > > > ownedthx wrote: >> >> The injected page 'trick' probably is not going to work. the action >> attribute of the form, unsuprisingly, points back to the path of that >> injected page; not where the form is in the page actually using this >> block from the injected page. Understandable. >> >> Maybe I can return the component as the response to a render phase >> method. That should also avoid recursion detection. Just have to try I >> guess. >> >> Seth >> >> >> ownedthx wrote: >>> >>> Hi all, >>> >>> Tapestry doesn't allow nested components. Ok, no problem. >>> >>> However, there is a situation where, say in component A's template, that >>> I want to define a block which has a reference to component A--but I'll >>> only call that component in a Zone update via Ajax. In other words, >>> there isn't actually recursion going on, because in a full page refresh, >>> the block isn't rendered, and when the zone is updated with Ajax, the >>> component is rendered but that's OK because it's parent isn't being >>> rendered. >>> >>> Regardless, Tapestry get's mad, warning me about recursion if I put that >>> block in the page. Ok, fine, so I try to get around that. I have an >>> approach that works ... almost: I made a 'worker' page, which has >>> nothing but a block defined--the block with the component A. I then >>> inject that page into my component, (using @InjectPage) and then on Ajax >>> request to my component, I use a public getter to retrieve the block >>> from this injected page, and return that. >>> >>> I'm having some sort of issue though; if that block from the injected >>> page contains a form, and I then submit that form, tapestry throws an >>> exception; I believe the path in the action attribute on the form does >>> not correctly point to a component. Still debugging that. >>> >>> Are there other ways to avoid Tapestry recursion detection in this >>> scenario? >>> >>> Regards, >>> Seth >>> >> >> > > -- View this message in context: http://n2.nabble.com/Avoiding-recursion-detection-in-ajax-situations-tp3681731p3686180.html Sent from the Tapestry Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
