[Neos] [Discussion] Neos coding best-practices

[Dmitri Pisarev]

Dear Neos experts!

Christian Müller on IRC touched a very interesting subject that I struggle
with since I use Neos -- coding best practices. There are multiple ways to
solving the same problem with Neos, and such diversity is its big strength,
but for beginners like me it is hard to understand what are pros and cons
to each solution, which leads to uncertainty and vagueness when designing a
system with Neos.

I think TYPO3.Neos.NodeTypes package would be a good basis to discuss such
best-practices, as it's a piece of code that all of us know well.

Let's begin with TextWithImage object. Current implementation uses Fluid
partial to store all of its backend/security logic and linking stuff. The
problem is that its really not fun to extend it: to add some class to an
image, you have to @override template in TS, copy partial together with all
of its security logic and finally add needed class... A bit frustrating for
beginner, who just want to add some responsive class to an image.

Now it's a lot easier to override some part of TypoScript code, than it is
with Fluid. We could either build the whole thing in TypoScript, or just
move more things to TS, like provide attribute object to figure and use TS
Image object for rendering an image.

*Suggestion: keep Fluid templates as lean and logic-less as possible.*


Another question that we stumble upon when designing image object is
NodeTypes design: SuperTypes (mixins) vs. ChildNodes.

The problem with mixins: no encapsulation of code. I.e. title from
HeadingMixin may easily overlap with ImageMixin's title if we use both
together.

As an alternative our TextWithImage nodeType could be composed of two
independent nodeTypes: Text and Image.

*Suggestion: SuperTypes are better be used for sub-typing and ChildNodes
for relation of composition.*
Could be interesting to discover more analogies between NodeTypes and UML...


Now I have questions to other nodeTypes too... The Grid implementation
allows fixed number of columns -- not too flexible. Say you want to change
number of columns is some Grid row -- that would require a lot of
node-moving... I prefer more flexible variant:
https://github.com/sfi-ru/Sfi.Grid/blob/master/Configuration/NodeTypes.yaml

AssetList -- better design would be to have an Asset TS object, and let
AssetList be just a lightweight iterator over Assets. That would allow
easier overriding and rendering a single asset object too. But this is a
tricky subject -- in fact AssetList is a medium between two worlds, as
assets are not part of TYPO3CR tree.


This are my 2 cents, add the topics that you are not certain about, so we
could start a discussion.

We planned for tomorrow to have *a short talk in hangouts* discussing this
question. It would be great if more people with various skill levels could
join the discussion.

I'll be around from 7:30am to 4:30pm CET in IRC, so let's set the time for
hangout there.

Yours,
Dmitri Pisarev