[TYPO3-mvc] Issues with "@cascade remove" and forms with nested objects

Franz Koch typo3.RemoveForMessage at elements-net.de
Sun May 19 18:15:46 CEST 2013


Hey folks,

long time no see. I think I found a bug, but need confirmation/thoughts

Setup:
Extbase 1.4 (unfortunately can't update), but this should also apply 
even to 6.x according to the code (unless I missed something in the 
rewritten propertyMapper)

Situation:
I just wrote a simple blog like extension for a customer with the 
possibility to upload pictures and assign a caption to them. The 
pictures are themselves a domain object holding a filename and a caption 
property and are connected to the post object as ObjectStorage.
In the create and edit forms, the blogger can dynamically add more 
upload fields with caption and ofc edit/delete existing.

Issue:
This all is working fine and gets mapped and persisted correctly as long 
as I haven't set the "@cascade remove" annotation for the pictures 
property. As soon as I add the annotation, ALL already persisted 
pictures get deleted when I update the blog post even if nothing changed 
at all and the property is correctly filled.

Possible bug/cause:
After debugging this for some hours now I think I found the cause. When 
I update the modified post in the repository, the persistence backend is 
calling "getRemovedChildObjects" in it's "persistObjectStorage" method, 
and "getRemovedChildObjects" always returns ALL contained objects even 
when nothing got removed.
All this method internally does is a simple check if the current 
objectStorage contains all objects that exist in the clean property by 
comparing their spl_object_hash and returns all that are not contained. 
And this is the issue, because all nested picture objects got cloned in 
the PropertyMapper as they where submitted via the edit form and thus 
have a different spl_object_hash. So either the "getRemovedChildObjects" 
has to compare the (U)UID in case of DomainObjects or the PropertyMapper 
must not clone any object which is no aggregate root and thus not 
monitored by the persistenceManager.



I fixed the issue for now by doing some dirty remapping of the pictures 
using their uncloned originals in a overridden internal actionController 
method.


-- 
kind regards,
Franz Koch


More information about the TYPO3-project-typo3v4mvc mailing list