Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Fluid forms for deep object forms and validation results #1585

Open
albe opened this issue May 19, 2019 · 5 comments

Comments

Projects
None yet
2 participants
@albe
Copy link
Member

commented May 19, 2019

See #1570 (comment)

In short, the following template should work as expected:

<f:for each="{allFormObjects}" as="formObject" key="index">
   <f:form objectName="objectDto.{index}" object="{formObject}" ...>
       <f:form.textfield property="myField" ... />
       <f:validation.results for="myField">
               ...
       </f:validation.results>
   </form>
</f:for>

i.e. the objectName should accept a path and f:validation.results should take the path prefix from an existing formObjectName ViewHelperVariable.

Currently, to achieve the same result, the template needs to look like this:

<f:for each="{allFormObjects}" as="formObject" key="index">
   <f:form objectName="objectDto" object="{allFormObjects}" ...>
       <f:form.textfield property="{index}.myField" ... />
       <f:validation.results for="objectDto.{index}.myField">
           ...
       </f:validation.results>
   </form>
</f:for>

Main issues here:

  • The f:form is bound to the allFormObjects DTO, which is weird, because we want to create a form for a single (sub)entity
  • We need to repeatedly prepend {index}. for ALL form field "property" attributes
  • We need to prepend objectDto.{index}. for ALL f:validation.results "for" attributes
  • Form field "property" and validation.results "for" look differently, even though they refer to the same property (path)
@kaystrobach

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

I still would expect, that we can simply supply some kind of form id (maybe the object identifier), to bind forms predictable, if no identifier is bound, the object might be used to "guess" the identifier.

the id should not be the html attribute id, as this might be filled with something else.

@albe

This comment has been minimized.

Copy link
Member Author

commented May 22, 2019

You could replace {index} in the above example with the object identifier, or whichever unique ID you have deterministically available during Form rendering. Mind that the object identifier might not be existing yet in an object creation form.

@kaystrobach

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

you mean:

   <f:form objectName="objectDto.{index}" object="{formObject}" ...>

sure, with an DTO.

What i meant was:

   <f:form objectName="object" object="{object}" internalFormIdentifier="{object -> f:format.identifier()}">

So we won't need to create a DTO here.

@kaystrobach

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

DTO's won't solve all cases, esp. if you have an extensible view, which might get the problem with third party forms.

@albe

This comment has been minimized.

Copy link
Member Author

commented May 24, 2019

The issue with

  <f:form objectName="object" object="{object}" internalFormIdentifier="{object -> f:format.identifier()}">

or to stay closer to the actual use-case:

<f:for each="{objects}" as="object">
  <f:form objectName="object" object="{object}" internalFormIdentifier="{object -> f:format.identifier()}">
  ...
</f:for>

is

  • the object identifier potentially isn't known at form rendering time (unless it is an edit form, but the framework doesn't know this)
  • with this the framework somehow needs to keep track of additional identifier and pass it through all the stack (Fluid -> Http -> Mvc -> Controller -> Fluid)
  • the frontent needs to keep track itself too, i.e. a map of index => identifier (or have the identifier stored inside the pre-persisted object, i.e. the object-identifier for an edit form or the identifier be fully deterministic independent of the actual object, so a counter = foreach index)
  • all this needs to be heavily documented to be understandable why, when and how this works

So this will basically never work well for the case of a create object form without a lot of magic and assumptions in place. But it works perfectly fine with the DTO, because that closer models what you are actually doing with this kind of multi-form, i.e. editing one of multiple entities from a given collection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.