Ok, got it working. The end result was that I created the following in order to do this:
1) A custom service which I use to retrieve the block from the injected page. While retreiving the block, I have to tell this service what the real form component should be, essentially. 2) An outbound url rewriter, that uses that custom service to convert form links pointing to the injected page to the page doing the ajax. 3) A mixin which setupRender/cleanupRender wraps AbstractField. WHat I do is I slip in my own FormSupport into environment for any AbstractField (the most base class of form fields), so that I can intercept the store() method, in which I return the ajax page's component instead of the injected pages component, so that t:formdata hidden field 'points' to the ajax page's form and not the injected one. Not alot of code, but a ton of work and investigation. ownedthx wrote: > > I tried url rewriting the outbound action attribute to match the component > form, instead of the form from the injected page. > > It causes the event to raise now in the right form... but all the form > field data are sent to the form in the injected page, because that big > nasty hidden input field that tapestry injects in ever form, once decoded, > tells Tapestry to send the form field data to that other form. I always > wondered what that hidden data was doing. I guess, in this circumstance, > I can not use the field in my own form (which is null) but instead decode > the hidden field data in my component using ClientDataEncoder, retrieve > the form from the injected page by ID, and then grab it's values... > > Seth > > > Robert Zeigler 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: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >> > > -- View this message in context: http://n2.nabble.com/Avoiding-recursion-detection-in-ajax-situations-tp3681731p3693166.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
