[
https://issues.apache.org/jira/browse/TAP5-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17841452#comment-17841452
]
Ben Weidig commented on TAP5-2774:
----------------------------------
Thank you for the test files!
I'm still a little confused about the whole setup, but I think I understand
what you're getting at.
As I understand it, even though Form A isn't an enclosing form in the TML, the
construct of partially rendering it in the submit kind of nests is due to the
RenderCommands.
Personally, I find the PartialTemplateRenderer + outputRaw a little unusual.
The tests in Tapestry itself use the PartialTemplateRenderer this way to verify
it's working, but the documentation states that it's supposed to render HTML
for external use like mails, etc., not normally rendered stuff.
For example, we use it in combination with Thymeleaf for mail generation.
[https://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/PartialTemplateRenderer.html]
I'd suggest using the normal rendering mechanisms, like t:delegate
{code:java}
public class FormTest {
@Inject
private AjaxResponseRenderer ajax;
@InjectComponent
private Zone zone;
@Inject
private Block initialBlock, templateBlock;
private boolean renderBlock;
@Property
private String someText1, someText2;
void onSuccessFromFormA() {
this.renderBlock = true;
this.ajax.addRender(this.zone);
}
public Block getBlock() {
return this.renderBlock ? this.templateBlock : this.initialBlock;
}
}
{code}
{code:xml}
<t:zone t:id="zone">
<t:delegate t:to="prop:block" />
</t:zone>
<t:form
t:id="formA"
async="true">
<t:textfield
t:id="field"
value="someText1" />
<t:submit />
</t:form>
<t:block id="initialBlock">
Hello There!
</t:block>
<t:block id="templateBlock">
<t:form t:id="formB">
<t:textfield value="someText2" />
</t:form>
</t:block>
{code}
Nevertheless, the question is if the PartialRenderService should or shouldn't
be affected by the current non-partial rendering environment. I see arguments
for both, depending on the use-case.
I didn't dig deep into the issue, so I can't say if there's an easy way around
the FormSupport/Environment issue, and what is needed to make
PartialRenderService more flexible.
But my educated guess is that it's not a trivial change.
For the time being, I'd suggest using t:delegate with conditional blocks. Or if
the forms are too complex to handle easily on the Tapestry side, I'd be using
TypeScript + Ajax to do it myself.
You can even trigger zone-refreshs from the client side, and thanks to
@PublishEvents / @RequestParameter, handling is quite straightforward.
> Form in form error when forms are not inside one another.
> ---------------------------------------------------------
>
> Key: TAP5-2774
> URL: https://issues.apache.org/jira/browse/TAP5-2774
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.8.2
> Reporter: Maximillian Steinbach
> Assignee: Ben Weidig
> Priority: Critical
> Attachments: Test.java, Test.tml
>
>
> I have t:form (form A) with an onSubmit action. This form's submit action
> triggers an ajax reload. The part of the page that is being reloaded is
> different to that of form A. The area being reloaded contains another t:form
> (form B) that must be re-rendered. While it is re-rendering form B it hits an
> exception at
> org.apache.tapestry5.corelib.components.Form.setupRender(Form.java:330)
> The error is "Form components may not be placed inside other Form
> components."
> It seems that there is a check here to see if there is an existing outer
> enclosing form in the process of being rendered. However the existing form it
> finds is the form A that is not an enclosing form, it is the form that
> triggers the submit action. Form A seems to be pushed into the environment on
> line 503 in the method onAction.
> I have taken a look at the git history here and there doesn't seems to have
> been any recent changes to this code so I am confused why this issue has
> begun on my end.
> As such, the result of this bug seems to be that a form's onSubmit action can
> never trigger the reload of another component that itself contains a form.
> This seems to be problematic.
> I can take a look at addressing this issue myself but I would appreciate
> other's more experienced input first before I attempt it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)