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
