Hi Robert, The issue of recursion I can fully appreciate. To have what I want to work, the structure algorithm would have to take into account more than it does now. So I opened a feature request for that (not a bug :))
I tried what you suggested, thanks. The issue is still the same, though. It renders on zone update ok enough, but the action attribute on any form contained in this component pulled from the other page still 'point' to the original page hierarchy; not the one I'm actually on, causing Basically it's something like this. A form created on the full page request has a hierarchy like this: /some-page.path.to.my.component.myform A form created with this component from the other page has an action attribute like this: /some-page.treerenderer.myform I'll try my best to explain. The scenario I have is like this: I have a component which renders a tree basically derived from our data model. I'll call this component 'treerenderer'. This tree is your standard DOM-like tree. We have many types of nodes in this tree in the data layer, and a matching tapestry component for each type of component. This tree is completely user-driven (pulled out of the database), hence the need for a master component responsible for rendering the tree. Ok, some of these components have forms defined in them. In the example good path above, the 'path.to.my.component' is basically 'n' deep, just depending on how deep the component is in that particular tree instance from the database. So the problem scenario is this: someone may do something in the form that requires us to re-render a portion of the tree. Ideally, we could render just that portion of the tree. In other words, I want to re-render just a piece of that tree with zones. The problem, of course, is that we are using this tree renderer component at the highest point in the page to initially render the page... and so trying to use it again within one of these tree components causes recursion to be detected. On Sep 21, 2009, at 12:10 PM, Robert Zeigler (via Nabble) wrote: > The problem is that even though there is no recursion in the / > rendering/, per se, there is recursion in the structure. > All recursive routines (and even having A => B => A is a recursive > structure) have to have a stop condition; the problem is that the stop > condition for rendering is only known when rendering, and tapestry > can't know it when building the /structure/ of the page. Ergo, the > strict structure requirements. > I think you were on the right track with the injected page trick, > although I would probably have taken a slightly different track, using > component source to retrieve the page and corresponding component. > Also, if there's a Form in A, and your including A => B => A, does > that mean you have a nested form?? > With a bit more information about the specific details of what you're > trying to accomplish, the list might be able to propose a solution > that will work for you. > > Cheers, > > Robert > > On Sep 20, 2009, at 9/205:01 PM , 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-tp3681731p3681839.html > > Sent from the Tapestry Users mailing list archive at Nabble.com. > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [hidden email] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > View message @ > http://n2.nabble.com/Avoiding-recursion-detection-in-ajax-situations-tp3681731p3686854.html > To unsubscribe from Re: Avoiding recursion detection in ajax > situations., click here. > -- View this message in context: http://n2.nabble.com/Avoiding-recursion-detection-in-ajax-situations-tp3681731p3687447.html Sent from the Tapestry Users mailing list archive at Nabble.com.
