[TYPO3-core] Domain model "page"

[Helmut Hummel]

Hi Philipp!

tl;dr: Stay Calm, we eventually will get there :)

Philipp Wrann wrote:
>> Any domain model which represents the content structure *must* incorporate this key feature.
>
> I dont think so but i am sure you know better. So please tell me what i miss.

I think we all basically want the same on a high level. I was talking 
about the low level implementation which just would not be just done by 
introducing anaemic Domain Models for pages and tt_content

> In default content elements i have text/textpic/list, etc ... And i could simply use a Template for each of those.
> If a content represents a userfunction (extbase, pibase, userobject) its also easy to render it.
> If a key is defined like tt_content.foo < tt_content.text some fallback processes it with the legacy renderer.
>
> Something like a public render method could do the job.

I'm not sure if I understand you correctly here, but yes, for 7LTS it is 
planned to render each content element with an according Fluid template. 
This has nothing to do with domain modeling however.

> If its about adding some field to the content element an integrator could achieve this by overloading the content model in the extbase setup.as

This is easier said than done and my (our) main point why we can't just 
provide raw models which act as not extendable data container.
Besides that, by doing so now, we would add yet another hurdle for 
integrators to reliably implement custom content elements. We're working 
hard to make that easier. Making it more complicated would be couter 
productive.

As written before, extensability must be a built in concept. It is one 
of the key features of TYPO3 if not any CMS. Even otherwise great 
Extensions like ext News implement a hacky extensability feature for its 
"Domain Model". Instead of delivering such a hack or putting the burden 
to deal with extensability to the integrator, we should ship a solid 
data container model which is easily configurable and extensible.

> With some viewhelpers like:
>
> <frontend:content.load column="left" fuzzy="1" />
>
> or
>
> <f:for each="{myObject.contentElements}" as="{content}">
> <frontend:content.render>{content.uid}</frontend:content.render>
> </f:for>
>
> Setting up a new TYPO3.CMS template would be much more fun.

Sure. A lot of that you get by using the Fluid powerd TYPO3 approach[1]

There are plans to go in this direction and we're working hard to pave 
the way, but it is a lot of work especially when cosidering backwards 
compatibility, technical brilliance, future proofness and full 
felxibility at the same time. A lot of cleanup needs to be done and was 
already done in this area.

> With your own page- and content-repository you could load menus and contents much more domainspecific and in a way not so pagetree-focused.

Not sure what you mean with "page- and content-repository" and if it 
helps to technically tackle our demands, but yes, a more defined and 
flexible way to fetch the content is desired.

But believe me, this is not done by only providing two content 
repository and two "domain model" classes.

> What point do i miss here? Would it really be such a bad idea to have something like that in the typo3.cms core?

The page and content model (not a PHP class, but it is still a technical 
representation) in TYPO3 is much more powerful and much less buggy in 
terms of Flexibility, Language and Workspaces support, than Extbase 
Domain Models. This is a fact. We cannot igonre it, just because extbase 
Domain Model *look* nicer. They are just not approriate (enough) for the 
job. A lot of work needs to be done here …

Hope this explains it a bit better.

Kind regards,
Helmut

[1]https://fluidtypo3.org

-- 
Helmut Hummel
Release Manager TYPO3 6.0
TYPO3 CMS Active Contributor, TYPO3 Security Team Member

TYPO3 .... inspiring people to share!
Get involved: typo3.org