You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by ownedthx <se...@gmail.com> on 2009/09/20 23:15:46 UTC
Avoiding recursion detection in ajax situations.
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-tp3681731p3681731.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Avoiding recursion detection in ajax situations.
Posted by Peter Stavrinides <P....@albourne.com>.
This is an interesting use case! I for one wouldn't mind seeing an actual concrete example... perhaps it could make a nice topic for a wiki article, if you have the time.
regards,
Peter
----- Original Message -----
From: "ownedthx" <se...@gmail.com>
To: users@tapestry.apache.org
Sent: Tuesday, 22 September, 2009 17:47:27 GMT +02:00 Athens, Beirut, Bucharest, Istanbul
Subject: Re: Avoiding recursion detection in ajax situations.
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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Avoiding recursion detection in ajax situations.
Posted by ownedthx <se...@gmail.com>.
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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Avoiding recursion detection in ajax situations.
Posted by ownedthx <se...@gmail.com>.
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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://n2.nabble.com/Avoiding-recursion-detection-in-ajax-situations-tp3681731p3689557.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Avoiding recursion detection in ajax situations.
Posted by ownedthx <se...@gmail.com>.
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.
Re: Avoiding recursion detection in ajax situations.
Posted by Robert Zeigler <ro...@scazdl.org>.
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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Avoiding recursion detection in ajax situations.
Posted by ownedthx <se...@gmail.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Avoiding recursion detection in ajax situations.
Posted by ownedthx <se...@gmail.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Avoiding recursion detection in ajax situations.
Posted by ownedthx <se...@gmail.com>.
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-tp3681731p3681763.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org