You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by jsauer <jo...@catalysts.cc> on 2012/01/03 11:25:57 UTC
Re: 5.3 Too much environment cloaking bug
Hello,
we're currently updating Tapestry from 5.2.6 to 5.3.1 and we're running into
the exact same problem as this message from November described:
Denis Stepanov-2 wrote
>
> Second, ajax request will lose environments set in its action method:
>
> Object onAction(EventContext context)
> {
> environment.push(...);
> return myBlock; // environment is cloaked while rendering myBlock
> }
>
> myBlock is a block from a different page, which uses the environment as a
> way how to communicate, concept similiar to the BeanEditor and its
> contributions.
>
We also use the environment to pass parameters between the main page and
contributed blocks. This works fine as long as the contributed blocks aren't
rendered via Ajax (for example when using ProgressiveDisplay). As there's no
documentation of any change like this in the release notes, I'd consider
this a bug as well.
Are there any plans to change this behaviour or any suggestions for a
solution?
regards
Joachim Sauer
--
View this message in context: http://tapestry.1045711.n5.nabble.com/5-3-Too-much-environment-cloaking-bug-tp5005584p5116592.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 5.3 Too much environment cloaking bug
Posted by Howard Lewis Ship <hl...@gmail.com>.
For clarification: the uncloaked FormSupport would cause an error
about illegally nested forms, which is inaccurate and misleading.
On Tue, Jan 3, 2012 at 2:29 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> This has changed "For The Greater Good". I don't think it can be
> changed back or made optional in any reasonable way.
>
> The specific case being handled was to deal with form submissions that
> want to immediately render a response that includes a form ... without
> cloaking the Environment, the FormSupport inside the environment would
> cause an error when a Form started to render.
>
> The fact that what you wrote worked is a problem, in that you do not
> balance the environment, but rely on it being discarded even though
> not everything pushed onto it was later popped.
>
> Perhaps you could return a Block containing:
>
> <t:block id="renderWithEnvironment">
> <t:trigger event="setupEnvironment"/>
> <t:delegate to="blockToRender"/>
> <t:trigger event="cleanupEnvironment"/>
> </t:block>
>
> This would allow Tapestry to just render your block; inside your
> block, the setupEnvironment event would be where you would push into
> the environment; the blockToRender would be the value you'd normally
> return from your onAction() event handler method. The
> cleanupEnvironment event would be used to pop the value out of the
> environment.
>
> Thoughts?
>
>
> On Tue, Jan 3, 2012 at 2:25 AM, jsauer <jo...@catalysts.cc> wrote:
>> Hello,
>>
>> we're currently updating Tapestry from 5.2.6 to 5.3.1 and we're running into
>> the exact same problem as this message from November described:
>>
>>
>> Denis Stepanov-2 wrote
>>>
>>> Second, ajax request will lose environments set in its action method:
>>>
>>> Object onAction(EventContext context)
>>> {
>>> environment.push(...);
>>> return myBlock; // environment is cloaked while rendering myBlock
>>> }
>>>
>>> myBlock is a block from a different page, which uses the environment as a
>>> way how to communicate, concept similiar to the BeanEditor and its
>>> contributions.
>>>
>>
>> We also use the environment to pass parameters between the main page and
>> contributed blocks. This works fine as long as the contributed blocks aren't
>> rendered via Ajax (for example when using ProgressiveDisplay). As there's no
>> documentation of any change like this in the release notes, I'd consider
>> this a bug as well.
>>
>> Are there any plans to change this behaviour or any suggestions for a
>> solution?
>>
>> regards
>> Joachim Sauer
>>
>> --
>> View this message in context: http://tapestry.1045711.n5.nabble.com/5-3-Too-much-environment-cloaking-bug-tp5005584p5116592.html
>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 5.3 Too much environment cloaking bug
Posted by Joachim Sauer <jo...@catalysts.cc>.
Hello,
Unfortunately this solution doesn't solve the complete problem for us (as
detailed below), I'm open to suggestions on how else to pass parameters to
arbitrary contributed blocks. Putting the relevant information in the
Environment is (was?) an elegant solution for this.
Howard Lewis Ship wrote
>
> Perhaps you could return a Block containing:
>
> <t:block id="renderWithEnvironment">
> <t:trigger event="setupEnvironment"/>
> <t:delegate to="blockToRender"/>
> <t:trigger event="cleanupEnvironment"/>
> </t:block>
>
> This would allow Tapestry to just render your block; inside your
> block, the setupEnvironment event would be where you would push into
> the environment; the blockToRender would be the value you'd normally
> return from your onAction() event handler method. The
> cleanupEnvironment event would be used to pop the value out of the
> environment.
>
I've tried this solution, but it's only a partial one for us, it has two
problems:
* it would need to be applied at every point where such a construct is used
and introduces quite some complications as well
* it only fixes the case where the environmental value is needed during
rendering
In our specific case the blocks might trigger other event, which in turn
again need access to the environment and also can't access it. Implementing
the fix suggested above doesn't help here, as the original page/template
that could set up the environment is no longer directly involved.
regards
Joachim Sauer
--
View this message in context: http://tapestry.1045711.n5.nabble.com/5-3-Too-much-environment-cloaking-bug-tp5005584p5119460.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 5.3 Too much environment cloaking bug
Posted by Josh Canfield <jo...@gmail.com>.
> The fact that what you wrote worked is a problem, in that you do not
> balance the environment, but rely on it being discarded even though
> not everything pushed onto it was later popped.
It would be nice if there were lifecycle methods around events so that
the event could be cleaned up.
> <t:block id="renderWithEnvironment">> <t:trigger event="setupEnvironment"/>> <t:delegate to="blockToRender"/>> <t:trigger event="cleanupEnvironment"/>> </t:block>
I feel dirty putting code like this into templates... it feels like a
workaround for something that should be solved more elegantly.
Josh
On Tue, Jan 3, 2012 at 2:29 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> This has changed "For The Greater Good". I don't think it can be
> changed back or made optional in any reasonable way.
>
> The specific case being handled was to deal with form submissions that
> want to immediately render a response that includes a form ... without
> cloaking the Environment, the FormSupport inside the environment would
> cause an error when a Form started to render.
>
> The fact that what you wrote worked is a problem, in that you do not
> balance the environment, but rely on it being discarded even though
> not everything pushed onto it was later popped.
>
> Perhaps you could return a Block containing:
>
> <t:block id="renderWithEnvironment">
> <t:trigger event="setupEnvironment"/>
> <t:delegate to="blockToRender"/>
> <t:trigger event="cleanupEnvironment"/>
> </t:block>
>
> This would allow Tapestry to just render your block; inside your
> block, the setupEnvironment event would be where you would push into
> the environment; the blockToRender would be the value you'd normally
> return from your onAction() event handler method. The
> cleanupEnvironment event would be used to pop the value out of the
> environment.
>
> Thoughts?
>
>
> On Tue, Jan 3, 2012 at 2:25 AM, jsauer <jo...@catalysts.cc> wrote:
>> Hello,
>>
>> we're currently updating Tapestry from 5.2.6 to 5.3.1 and we're running into
>> the exact same problem as this message from November described:
>>
>>
>> Denis Stepanov-2 wrote
>>>
>>> Second, ajax request will lose environments set in its action method:
>>>
>>> Object onAction(EventContext context)
>>> {
>>> environment.push(...);
>>> return myBlock; // environment is cloaked while rendering myBlock
>>> }
>>>
>>> myBlock is a block from a different page, which uses the environment as a
>>> way how to communicate, concept similiar to the BeanEditor and its
>>> contributions.
>>>
>>
>> We also use the environment to pass parameters between the main page and
>> contributed blocks. This works fine as long as the contributed blocks aren't
>> rendered via Ajax (for example when using ProgressiveDisplay). As there's no
>> documentation of any change like this in the release notes, I'd consider
>> this a bug as well.
>>
>> Are there any plans to change this behaviour or any suggestions for a
>> solution?
>>
>> regards
>> Joachim Sauer
>>
>> --
>> View this message in context: http://tapestry.1045711.n5.nabble.com/5-3-Too-much-environment-cloaking-bug-tp5005584p5116592.html
>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 5.3 Too much environment cloaking bug
Posted by Howard Lewis Ship <hl...@gmail.com>.
This has changed "For The Greater Good". I don't think it can be
changed back or made optional in any reasonable way.
The specific case being handled was to deal with form submissions that
want to immediately render a response that includes a form ... without
cloaking the Environment, the FormSupport inside the environment would
cause an error when a Form started to render.
The fact that what you wrote worked is a problem, in that you do not
balance the environment, but rely on it being discarded even though
not everything pushed onto it was later popped.
Perhaps you could return a Block containing:
<t:block id="renderWithEnvironment">
<t:trigger event="setupEnvironment"/>
<t:delegate to="blockToRender"/>
<t:trigger event="cleanupEnvironment"/>
</t:block>
This would allow Tapestry to just render your block; inside your
block, the setupEnvironment event would be where you would push into
the environment; the blockToRender would be the value you'd normally
return from your onAction() event handler method. The
cleanupEnvironment event would be used to pop the value out of the
environment.
Thoughts?
On Tue, Jan 3, 2012 at 2:25 AM, jsauer <jo...@catalysts.cc> wrote:
> Hello,
>
> we're currently updating Tapestry from 5.2.6 to 5.3.1 and we're running into
> the exact same problem as this message from November described:
>
>
> Denis Stepanov-2 wrote
>>
>> Second, ajax request will lose environments set in its action method:
>>
>> Object onAction(EventContext context)
>> {
>> environment.push(...);
>> return myBlock; // environment is cloaked while rendering myBlock
>> }
>>
>> myBlock is a block from a different page, which uses the environment as a
>> way how to communicate, concept similiar to the BeanEditor and its
>> contributions.
>>
>
> We also use the environment to pass parameters between the main page and
> contributed blocks. This works fine as long as the contributed blocks aren't
> rendered via Ajax (for example when using ProgressiveDisplay). As there's no
> documentation of any change like this in the release notes, I'd consider
> this a bug as well.
>
> Are there any plans to change this behaviour or any suggestions for a
> solution?
>
> regards
> Joachim Sauer
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/5-3-Too-much-environment-cloaking-bug-tp5005584p5116592.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org