Is this the (improvable) basic Neos website development pattern?

Using Neos & Flow
1

(The website development pattern should not be confused with the Flow/Neos application development pattern.)

The following tries to summarize the pattern as I understood it from reading the Neos docs, and then asks for your thoughts about introducing some default conventions that may simplify basic website creation a lot.




A kind of “Model-View-Controller” (MVC) for Neos power users.

The docs teach about how typoscript files need to be defined to process and feed data to the templates.
https://neos.readthedocs.org/en/stable/CreatingASite/TypoScript/index.html

Then the Flow templating language is explained, and it is noted in a special box:

The semantics between the controller and the view should be the following: The controller instructs the view to “render the blog object given to it”, and not to “render the Blog title, and the blog posting 1, ...”.
Passing objects to the view instead of simple values is highly encouraged!

https://neos.readthedocs.org/en/stable/CreatingASite/RenderingCustomMarkup/Templating.html
For the neos user it is the typoscript processing that corresponds the closest to the controller in an Model-View-Controller (MVC) pattern.

Therefore, I gather, the MVC pattern in the Neos website development scope works like this:
Data Model: The node definitions.
View: Defined by the html templates (with relatively simple Fluid iteration and include logic)
Controller: Very flexible typoscript processing system with full control about the data and the rending done by the template.

This fine pattern allows for great flexibility to build websites. The full control that the typoscript driven processing allows is a particularly powerfull tool. However, for many simple tasks the typoscript may merely be needed to associate nodes and properties to templates, everything else can be done in the powerful Flow templating language. For these basic areas of a website, the typoscript files may be seen as boilerplate. This boilerplate may be avoidable, and basic website creation may become much easier if Neos could introduce some sensible default conventions:

For example:

  • Default to loading .html files in the template directories that are exacly named after the document node type as template for this document node type, if not overridden otherwise in typoscript.
  • Default to make all node properties available indirectly (i.e. property = ${q(node).property(‘property’) if not overridden otherwise}
  • Default to make all content collection subnodes available within the template, if not overridden otherwise.

The full power of typoscript should remain available, but large parts of basic websites may be build by simply configuring node types and providing templates.

2

It’s funny, but this is exactly how things work now:
A TS object of type template is constructed for each node types automatically, and has its Fluid template set to Private/Templates/NodeTypes/YourNodeName.html . It has all properties automatically set to Fluid variables.
But yeah, no auto CC rendering, and it could be a good idea indeed to implement it this way.

Now for the best practices part… A year ago I wrote almost the same thing as you.
Now having gained more experience with JS frameworks like React, I no longer look at it through MVC lens.
How I look at it now: TYPO3CR is clearly a model, no question about that. TypoScript + Fluid is a view. TypoScript helps to frame your view in a more component-oriented pattern, where each object can be rendered out-of-band, separately from context that surrounds it. Fluid is best to be used for HTML templating, but not view logic like loops or even conditions. I try to keep Fluid templates as logicless as possible, e.g. I have almost zero f:for loops in my codebase, I prefer TypoScript:Collection to it.
This way to think about the view perfectly relates with React’s approach to UI.

3

It’s very good to hear that you Neos devs have already implemented sane defaults.

Well, I am sure you guys are also aware of the major point stifling my Flow/Neos adoption then.

The documention. Possibilities, patterns, conventions and logistics need to be explained, ideally with examples. Even in the reference sections, just listing methods without explaining their parameters doesn’t cut it. At all levels, start with presenting the involved parts that work together, explain what they do, and how they do it.

When looking at React JS refered to above, I liked how it keeps everything related to a component in one file. It may also be possible to “inline” the Flow templates in typoscript files. But it may make namespacing, adressing and switching of templates harder, or maybe not?

In any case, looking forward to see the base and example packages rely on the defaults and making Neos simpler.

4

Apropos making Neos simper.

Couldn’t the typoscript object definition files be written in a yaml like syntax? Similar to the node type definitions and application settings?

5

@cgat yep, docs is the priority now and we’re working hard on improving them. If you can help out with that in greater detail, get involved and contact the docs team!

Why would you want to inline Fluid in TS? I hear complaints about React for the lack of separation of concerns. E.g. designers just can’t edit its templates. But maybe this idea should be give more thought.

Regarding making TS use Yaml syntax: just no. Yaml is a configuration language, TS is way more than that. If we could reinvent the wheel I would just use React for rendering anyways.

6

Good point, Fluid templates that are dispersed into many small files can’t be loaded into an html editor to check and modify the design either.

Maybe it would make sense to keep the templates in larger layouts resembling some form of pages so that thay can be viewed in browsers or editors. While having typoscript logic refer to parts of these templates by using dom IDs etc.

Ok, but if there is a solution that is more readable and and makes supporting yet another languag unnecessary, consider why not? http://zenadmin.org/en/blog/post545.html

7

For true componentization, I think that the css and javascript required to render the component will also need to be defined or referenced from the same place. Be it the typoscript or the Flow template.

Overall, to me it seems that some form of “template sheets” would be the best way to define components. (Not naming them template pages to avoid confusion with the pages finally rendered based on the template sheets.).

In the template sheets, the component logic could be embedded as typoscript in the <header> so that html editors may just ignore it. The typoscript objects define components, refering to template sections further down in the current or another template sheet.

The css and javascript defined or loaded in a template sheet could define what will be included in the page together with the component when a page is rendered.

With this, one may define one component per template sheet, or multiple components that require the same css and javascript in one file.

A “package of components” would look like a directory of .html files that can be displayed in a browser immediately showing the designs with some explaining dummy text.