Feature #70634
closed
Proper view helper for generating nested / child records
0%
Description
If I'm wrong, I'll let you enlighten me happily.
Current situation
You want to provide a form where a user creates not just one model / record, but also n nested records, or child records (e.g.: when creating a Pizza object, you also create five Topping records associated with it).
In your form, you scramble something together with f:form.textfield for each Topping and either use the "property" or "name" attribute. However, this gives your form much more complexity, as you have to maintain the index for the params array (pizza[toppings][n][name]) yourself.
You also have to manually throw together some code into your initializeAction for extbase to not raise an error because your data is missing inside __trustedProperties.
Request for change
I'd say the following code snipped is a self-explanatory example about how it could work:
<f:form action="create" object="{pizza}" objectName="pizza">
// fields for pizza itself go here
<f:form.fields property="pizza.toppings" collection="{pizza.toppings}">
// fields for each pizza.toppings record go here.
// context for sub-properties is recognized.
// field for each topping's "name" property
<f:form.textfield property="name" />
</f:form.fields>
</f:form>
Updated by Claus Due over 8 years ago
- Status changed from New to Rejected
- Priority changed from Must have to Won't have this time
Hi Pascal,
First things first:
You also have to manually throw together some code into your initializeAction for extbase to not raise an error because your data is missing inside __trustedProperties.
This indicates that you're not using Fluid ViewHelpers to generate (all of) the fields. If for whatever reason that's intentional, there is one other way to add those to the checksum and posted property list:
https://fluidtypo3.org/viewhelpers/vhs/master/Form/FieldNameViewHelper.html
It does everything a normal form ViewHelper does regarding "property" and "name" - also for arrays of properties - but returns only the field name that you put in the "name" of your custom HTML input or whatever field.
Now to the meat and potatoes.
I remember three-four years ago when I created a feature that would do a small part of this. It is one of the most deceptively simple feature requests I can think of - it can be described in as few lines of template code as you provide above, but the implementation has ties to some heavy, heavy stuff. Let me tell you a little horror story ;)
Although at this point I've probably forgotten quite a few of the smaller problems, the bigger ones:
- HMAC/CSRF generation. It's easy enough to render for example X number of repeated form fields for sub-objects, but doing so during object creation has a heap of problems following with it. You still have to add the fields that would create new sub-objects in a special way, or there would have to be an internal switching in such a ViewHelper to make an "add new" form set above or below the collection, so that HMAC/CSRF can be maintained. This would make the ViewHelper probably generically useful, but almost all use cases I've come across have called for dynamically adding X number of new form set groups... and I don't even want to begin telling you about the various hacks one has to do to get something like that working. Supporting it in a generic ViewHelper I think is completely unrealistic - in order to even work it had to be so generic that it only fits some rather oldschool use cases.
- Internal form field name generation. Each ViewHelper would have to be adapted to become aware of a parent scope (recursively) and it would have to be implemented in a way that also supports custom subclasses of the core form ViewHelpers.
- Validation. You still have to add the validation results and that means knowing about the index; or we go back to the situation where validation results display becomes so generic (t3-form-error css class...) that it's useless in any modern markup framework context. It might be possible to solve with a new validation results ViewHelper or additional flags for the existing one, plus making it recursively aware of a parent context, but... it's quite a complex task.
There is the clear temptation to turn this into a Widget, but that's a trap. I can't explain all the pitfalls here but if you feel like a bit of pain one dead Sunday, you could try implementing a Fluid Widget that - just for example - renders a single sub-object for an 1:1 property, or even one that renders X number of form fields for an object. Then observe how much you have to work around to actually pass such entities back and forth, and how extremely hard (read: technically impossible) it is to make such a thing work in a cached page template or even just allowing Fluid to compile it.
All of this has to be put into this perspective: you currently have an easy way to do this that has none of the limitations above and every benefit - use Partials or Sections for your objects and pass things like form field name prefix, sub-object name and sub-object instance, then call that from a loop, condition, inside f:switch or whatever; and always use f:form field ViewHelpers for every field including submit buttons - and complement with v:form.fieldName when needed.
It isn't easy to explain in all detail how to do such a thing but I suspect you get it. My point it: on the surface your feature request is simple, but it is completely deceptive. Implementing it runs the very likely risk of becoming too generic to be even useful (see for example what happened to Widgets; specifically Ajax ones...) or simply introducing new edge cases that also must be supported. And it involves significant changes in the internal API of every form ViewHelper, introducing recursiveness among other things. So while I'm not happy about it, I still have to reject this one as just too extreme a thing to do when there is a workaround for it in the form of partials and sections plus any method you like that causes correct HMAC/CSRF generation.
That being said: if the HMAC/CSRF thing bothers you and you find that v:form.fieldName solves the issue then that particular ViewHelper is simple enough to include in Fluid (CMS; Flow would need it's own, too). And if you request it, I'll create the patch - as a way of saying sorry for rejecting this one after 5 days of short life ;)