Bug #69234
closed
f:cObject doesn't work with object properties
0%
Description
Hi there,
i struggled accross a behaviour in the f:cObject ViewHelper that does not let me access the properties of my domain object.
If i do something like this:
Fluid Template
<f:format.raw>
<f:cObject typoscriptObjectPath="plugin.ty_myext.content" data={frontendUser: frontendUser} />
</f:format.raw>
Typoscript
plugin.tx_myext{
content = CONTENT
content{
table = tt_content
select{
where = colPos=1
oderBy = sorting
pidInList = 0
}
stdWrap{
replacement{
10{
search = {%frontendUserFirstName}
replace.dataWrap = {field: frontendUser.firstName}
}
}
}
}
}
The string "{%frontendUserFirstName}" is found and replaced, but the replacement is an empty string instead of the frontend users first name, that is stored in the domain object of type "\TYPO3\CMS\Extbase\Domain\Model\FrontendUser".
If i do this:
Fluid Template
<f:format.raw>
<f:cObject typoscriptObjectPath="plugin.ty_myext.content" data={frontendUserFirstName: frontendUser.firstName} />
</f:format.raw>
Typoscript
plugin.tx_myext{
content = CONTENT
content{
table = tt_content
select{
where = colPos=1
oderBy = sorting
pidInList = 0
}
stdWrap{
replacement{
10{
search = {%frontendUserFirstName}
replace.dataWrap = {field: frontendUserFirstName}
}
}
}
}
}
everything works as expected. There might be a bug on the domain object handling of the f:cObject ViewHelper, because i thought it can handle domain objects in it's data attribute, as mentioned in the documentation: https://docs.typo3.org/typo3cms/ExtbaseGuide/Fluid/ViewHelper/CObject.html
I am on TYPO3 6.2.15-dev
Updated by Claus Due over 8 years ago
- Category changed from Fluid to Content Rendering
This would appear to be incorrect usage of the API. According to the documentation you link to, this would be the expected usage:
lib.myObject {
10 = TEXT
10.value.current = 1
}
And:
<f:cObject typoscriptObjectPath="lib.myObject" data="{frontendUser}" currentValueKey="firstName" />
That's what "handles domain objects in data attribute" means. Your example on the other hand is to create an ad-hoc array with a sub-property that is a domain object, which might very well cause the internals of ContentObjectRenderer to access the data in a different way. Which would be by design.
One might argue that the core should simply use ObjectAccess::getPropertyPath() to retrieve anything from the "data" array when rendering objects. However, it's likely that this would put significant additional load on every rendering in TYPO3 - and ObjectAccess already isn't the most efficient tool.
But you absolutely should reconsider your approach here. Performing a global search-and-replace on content output seems very risky and is almost bound to have side effects.
NB: do not do this in any context that can be cached. It will cache the username as part of the cached HTML; not even the built-in caching of TYPO3 based on user groups will be able to handle this. And if you absolutely, positively must do this, then I suggest instead using a page rendering hook that does this replacement with a standard str_replace on the output after it is retrieved from the cache. It'll be much more efficient (if as I suspect all your pages contain at least one instance of usersession-specific data).
Moved to "Content Rendering" since it definitely isn't a Fluid issue; if the API is used as documented. However, core team should consider supporting objects inside arrays since it is (I agree) a valid use case - although the frontenduser use case here isn't ideal to describe why (a page, site, content, etc domain model object would make much more sense since those don't depend on logins)
Updated by Kevin Ditscheid over 8 years ago
Sry for the bad example, you misunderstood it a little. Actually, i have a list of users whom i want to send e-mails. The templates for this mail can be generated as a domain object and filled by RTE with styling elements and these placeholders for the users name and so on. So i'm running through a list of frontendUser objects, render the mail templates in a standalone view and send the rendered content as the body text via the TYPO3 Message API to the email address, that is bound to every frontendUser object. This will be done in a none cacheable action of the controller, so i do not encounter this issues you have mentioned. It's basically a reminder functionality with custom mail templates, that the editor can edit in the backend.
Anyway, the last thing you mentioned was the intended message i wanted to sent :)
Updated by Helmut Hummel over 7 years ago
- Status changed from New to Rejected
replace.dataWrap = {field: frontendUser.firstName}
This has nothing to do with Fluid or domain object, but with TypoScript. In TypoScript the data of an content object can only be a flat array. You cannot access nested array structures at all.