Bug #57145
closed
FLUID viewhelper form.validationResults fails in sind Beta 6 (also Beta 7 and current master branch)
0%
Description
In TYPO3 6.1 this viewHelper don´t make any trouble, but TYPO3 6.2 since Beta 6 and after (and before?)
My editAction view render this partial, and fails:
<f:render partial="FormErrors" arguments="{object:issue}"/>
Call to a member function setParent() on a non-object in typo3/sysext/extbase/Classes/Error/Result.php on line 216
function in Result.php public function forProperty($propertyPath) {
if ($propertyPath === '' || $propertyPath === NULL) {
return $this;
}
if (strpos($propertyPath, '.') !== FALSE) {
return $this->recurseThroughResult(explode('.', $propertyPath));
}
if (!isset($this->propertyResults[$propertyPath])) {
$this->propertyResults[$propertyPath] = new Result();
$this->propertyResults[$propertyPath]->setParent($this);
}
return $this->propertyResults[$propertyPath];
}
My current fix:
dont use it^^
Files
Updated by Philipp Thiele over 10 years ago
- File 57145.diff 57145.diff added
problem still exists in 6.2.3, at least on windows machines with php 5.3.13
occurs when a whole model is validated, so that $propertyPath becoms an object
i fixed this for me by casting $propertyPath explicit to a string, see attached diff
Updated by Philipp Thiele over 10 years ago
sorry, i was wrong:
my patch didn't solve anything, it only suppresses the error.
infact, it is not a core bug, but a misuse of the formerror partial.
wrong example (assuming user is your domain model, assigned to fluid) wich will get you the error: <f:render partial="FormErrors" arguments="{object:user}"/>
<f:form action="create" name="user" object="{user}">
correct example (remark the quotes):<f:render partial="FormErrors" arguments="{object:'user'}"/>
<f:form action="create" name="user" object="{user}">
if someone falls back to the old property mapper this will not happen because the old one dosen't validate the whole object
Updated by Franz Holzinger about 10 years ago
This bug is still present in TYPO3 6.2.5.
The reason lies in file fluid/Classes/Core/ViewHelper/AbstractViewHelper.php.
protected function callRenderMethod() {
...
try {
return call_user_func_array(array($this, 'render'), $renderMethodParameters);
Here it calls extbase/Classes/Error/Result.php with an object as a parameter. However only a string parameter is allowed here.
* @param string $propertyPath
* @return \TYPO3\CMS\Extbase\Error\Result
* @api
*/
public function forProperty($propertyPath) {
The given object is e.g. 'Typovision\Simpleblog\Domain\Model\Blog' inside of the parameter $propertyPath.
Fatal error: Call to a member function setParent() on a non-object in Classes/Error/Result.php
This object has been fetched before inside of /fluid/Classes/Core/Parser/SyntaxTree/AbstractNode.php.
* @return mixed Normally, an object is returned - in case it is concatenated with a string, a string is returned.
public function evaluateChildNodes(\TYPO3\CMS\Fluid\Core\Rendering\RenderingContextInterface $renderingContext) {
$output = NULL;
foreach ($this->childNodes as $subNode) {
if ($output === NULL) {
$output = $subNode->evaluate($renderingContext);
AbstractNode::evaluateChildNodes allows the return of an object.
And the further connection to the Result.php gives a mismatch between object and string. How must this be fixed?
Updated by Ephraim Härer over 9 years ago
I had also problems with the class in Result.php and the attached patch fixed the problem for me (Version 6.2.12).
Please update the script for the next release!
Updated by Claus Due about 9 years ago
- Status changed from New to Closed
While I don't recall if this used to be different (the old property mapper may have used an ObjectStorage which supported objects - I just don't know), one thing is very clear: the usage examples given above are incorrect according to the ViewHelper argument descriptions.
According to those, the "for" argument on f:form.validationResults requires a string, not an object. And to my knowledge this was never different. That also makes sense if you compare to the API for the Result class, where "forProperty" clearly is a string..
If you feed an object instance into "for", which you do, Fluid is expected to break (maybe not with an error like this, but break nonetheless). The reason you aren't getting a Fluid-specific error (invalid argument type) may very well be that your domain object class has a __toString() method which means it passes as "string compatible" argument, which is formally correct according to argument types. While it might be possible to throw a better error message about this or accommodate string-compatible objects in the Result::forProperty method, or cast the object to a string in the ViewHelper itself... the source of the problem is inevitably incorrect use of API and can be avoided by making sure you pass a string property path instead of the instance of the object at that path.
Closing as "incorrect use of API; has workaround". While we could cast the object to string as suggested in the patch, it only hides the issue instead of solving it and still wouldn't return the correct validation results (since the string representation of the object isn't a valid property path).