Just to make it clear, i would prefer option 1 "move atomic.fusion to core and afx into the neos-namespace " since this would give us the option to define strong best-pratices with afx-components that rely only on packages in the neos-namespace. This would make teaching neos imho much easier.
To me the follow up questions matter when deciding this. If it’s included in the core for convenience and the NodeTypes package isn’t adopted, then I wouldn’t want it in the core. However if the core packages are adopted to the standard, then it might make sense IMO.
Atomic.Fusion is a opinionated and little more complex (learning curve) compared to how it is in the core currently as I see it. Although it’s definitely a good default, I see it as one of many ways to do things. When I look at the package, it’s about adopting that specific style of using Neos, something I’d be reluctant to personally.
On the other hand I have no problem adopting the package an approach supported by the Neos team and making it an official Neos package, but optional.
I was actually looking for an option to include AFX into the core instead of Atomic.Fusion as I see that as a more generic useful thing and not opinionated the same way but more a generic building block.
thanks for the Feedback. Offcourse if we integrate Atomic.Fusion into the core Neos.Demo or something similar has to be provided to help learning that approach. I only see this as a second step because there are some questions that have to be decided in that case. So adding Atomic.Fusion to the core would be the first step and as soon as this is done the discussion about Neos.NodeTypes and Neos.Demo could start.
Atomic.Fusion is a opinionated
Atomic.Fusion basically brings the Component fusion-prototype and some convenience prototypes that all make sense anyways. So the opinionated part is quite limited.
and little more complex (learning curve)
I really doubt that and also my experience from teaching Atomic.Fusion is different. With Atomic.Fusion and AFX new integrators do’nt need Fluid and thus never have to decide what should be done in a template or in fusion.
The current template-based approach might be partly familiar for people who know Fluid (aka TYPO3-Integrators) but is more confusing for everyone else. We managed to integrate frontend-developers into our workflow that previously never thought about working directly in a cms.
Not just TYPO3 integrators, Flow is based on Fluid so anyone working with Neos will very likely need to learn Fluid regardless as many parts rely on Fluid anyway. Looking at the AtomicFusion implementation of the demo site, there’s definitely a steeper learning than the current implementation due to the atomic methodology, styleguide etc.
However I’d be fine with adding the AtomicFusion helpers in the core, just not sure if I’d want to adopt it as the standard approach as it’s based on one specific frontend methodology. Although don’t see an issue using it for the Demo site as an example. Also would be fine with adjusting the rendering of the content elements in NodeTypes to be pure Fusion or AFX based instead.
Related to this is how it’s implemented and if it’s done in a backwards compatible way or breaking way. I could see it makes sense to implement the AtomicFusion stuff into the core for 3.3 without changing any existing code. Then for 4.0 we could consider altering the core and at the same time adjust page rendering to be node type prototype based instead of path based as default.
What I like about Neos is it’s focus on being a non-fat CMS without all kind of extras that might not be used and can be easily installed to extend Neos.
We try to use as less of Neos as possible, and select only what is required to do the job we need to handle. If “add to core” means making it a required part of Neos than I would be against it. It would only add more code for our installations for a feature I do not see as a core CMS feature. If it only means “including in the development repository” and keep it optional (maybe installed by default, I could handle that ) then I don’t care much.
So I think it would make sense to explain what the impact would be and what “adding to the core” really means
@aertmann@radmiraal Maybe it helps if i specify my ideas a bit more detailed.
By “adding Atomic.Fusion to the core” i mean transferring the fusion-prototypes from the Atomic.Fusion Package. “Component” would go to Neos.Fusion and “Content”, “Editable” and “Augmenter” to Neos.Neos. Those Prototypes make creating components in pure Fusion much easier but they enforce nothing. Especially not how you structure your fusion, js or css. In a way Atomic.Fusion would still be a pattern but the needed building blocks would become part of the core.
The AFX package would be moved to the Neos-Project as Neos.AFX but not to the Development Collection so while beeing “official” it would not be required at all.
If we agree on this i can do most of the work during the vienna-sprint and can discuss all the details there or in the pr’s. For now we just need a general agreement that we want that.
The motivation for all that is making Atomic.Fusion an “official” good-practice and enabling the following refactoring of Neos.Demo (or another demo package) to those patterns without relying on external packages.
For Neos.Demo and Neos.NodeTypes i would like to discuss on the sprint how exactly to proceed there. Neos.Demo would be the place where we could show a fusion-component system with clear destinction between presentation and integration plus js and css colocation as described in the Atomic.Fusion post https://www.neos.io/blog/atomic-fusion.html
Honestly I don’t have a deep knowledge about atomic, but reading above reply I can imagine myself using Editable and Content. But as said, I’m not hindered by deep knowledge of the package
By skimming the blog post about Atomic I can not see myself using that same structure. But that’s probably because we work with a CMS-agnostic set of components, and for such usecases I’m reluctant about adding code to the core that might not be used, or is really opinionated. I think such code would belong to a separate package, and not in Neos.Neos.
In my perfect world Neos.Neos would only be domain logic linking the CR, Fusion and some really CMS-y domain logic with a connector for a UI or something like that. It is already more than that, and that hinders me if I try to work with CR and Fusion rendering in a standalone matter without Neos for example. So I hope you see the point why I’d vote against adding more to the core, as I’d rather see a slimmer core.
Edit:
btw… I’d be all in for making the package “official” and putting it in the main dev repo and so on, but just in a completely removable package as I don’t like code lingering around if not used
I think it all boils down to custom distributions. Christian mentioned this somewhere, too: We need a way to easily install Neos in different flavors. At least sth like “Barebones”, “Kickstart” and “Demo” would be feasible IMO
I discussed the topic this morning with @mficzel and I see the point in those elements being part of the category “glue between content, rendering and editing” which IMHO means it belongs to what I would expect a Neos CMS feature indeed. So I understand the suggestion to put in the core and would say it fits.
) then I don’t care much.
