"Share your Flow appliction structure" documentation proposal/idea/request for definition

After a great chat on Slack with @david.sporer about his and mine project and structure I can see a “hole” in our documentation.

I ask myself the question:

  • How does others reallife application looks?
  • Are they having one package for each controller context?
  • Do they have a core package with some generic stuff?
  • A data package with models?
  • How and where do they store the Policy, when you create multiple packages for each controller context?

This is a number of questions I ask myself from time to time.

  • Do anyone else have these questions?
  • Do you have answers?
  • How do we collect and share these informations?

Do you know similar Q&A from others that we could copy/paste/adjust that to our needs and usecase?

Goal?

  • To serve as a documentation for us who knows Flow and the for pointer to new developers joining the community.
  • Talk loud and with each other about how we do and what we might be able to learn from each other
4 Likes

What I forgot in our chat: there’s a talk from this year’s Neos Con from Maya https://www.youtube.com/watch?v=zxd1yc2wlL4
This for sure includes things that can be used for such best practice.

The talk is really great regarding NodeTypes and NEOS CMS!

I’m hoping for something similar on how we structure larger projects that is not CMS based, but have features added a long the way.

I believe that we all have a number of usecases that we know from similar frameworks and would like to know how we do the same in Flow.

I’ve mentioned a few in my original post