Considerations about further missing TCA types

[nhovratov]

Image manipulation Only relevant for sys_file_reference crop field. Json Right now only used by the Core for reactions/webhooks. Need to find a use case for that. Language fields This is only used for the language system field and is generated automatically by Content Blocks. Does not need a dedicated type in my optinion. none Not sure, rarely used type. Does nothing on its own. Needs at least a custom renderType. Pass through / virtual field Has some viable use cases for plugins / extbase. For example non-persistent class properties. Custom inputs (user) No idea. Also needs a custom renderType like type none. Only difference seems to be that it needs a db field.

[nhovratov]

Any opinions on these types? Should we just add all to be "complete" or only those which make sense. It should be somehow possible to include custom implementations with renderType.

[jonaseberle]

Thanks! I'll try to imagine use cases...

---

json could be useful in cases where copy-pasting data is more productive than filling in many fields. I think of a use case where some web configurator (for a slider for a example) exports some data. Or table data that is edited in spreadsheets and can be exported as JSON. It could be a neat feature if our DataProcessors support it by delivering arrays the same way we support FlexForms. Since we don't have a json.decode ViewHelper in Core, that would make the json type easy to use.

language: In our context I can only think of using it together with a link to a specific website language. It supports all select properties AFAIK, so it could be used for multi-selecting website languages. I think it would warrant an implementation.

---

Achieving "type parity" at the time of release of v13 would have some marketing value for ContentBlocks. But it might attract use cases and thus feature creep or frustration that we are not really prepared to support. We would also have to implement them in our JSON schema and the GUI. And the "obscure" and hard-to-describe types also make the documentation more abstract. IMHO the goal should still be to "make TYPO3 content definition easier".

So in my opinion it is OK if we don't have all TCA types. Advanced usage can be done by TCA overrides. What do others think?

[nhovratov]

Type Json added: https://github.com/nhovratov/content-blocks/commit/438a6ad01c2dcd7e3b9d1b2cfacbe3b9e52fc170 Thanks to @PKuhlmay

[nhovratov]

I think the next one should be type passtrough. We could call it Pass or Virtual for simplicity. As it has no rendering in the backend, this could also be a list in the yaml file:

virtualFields:
  - foo
  - bar

Not sure though. They can have a default value. This would be missing here.

These are just appended to the TCA columns list and a db field is generated as type text. Needs a check for uniqueness and whether it is a system field like pid. This would be valid, but could skip the db generation. In v13 this is automatic, too.

[garvinhicking]

Hm, I think in terms of TYPO3 this "passthrough" is more established and known to developers and integrators, and IMO it describes what's happening a bit better than "Virtual" (which may suggest that the field does not really exist, when in fact, it does and its existance is exactly why you need the TCA?).

$0.02 ;)

[jonaseberle]

We talked about the missing types in our public team meeting.

We'd like to add language. We currently tend to not add the others.

We'll keep this issue open until the Core patch merge review where we anticipate more discussion about it.

[nhovratov]

Type user will be obsolete with this patch: https://github.com/nhovratov/content-blocks/pull/150

[nhovratov]

I think we need type passthrough as Content Blocks is more and more used with Extbase context.

[nhovratov]

Type "Pass" added: https://github.com/nhovratov/content-blocks/commit/065409a99818cc45e829652b7eb85c28b95d8251