Funding request: [Flow Light] Split doctrine integrations (validation etc) from Neos.Flow and move to own persistence package

[sorenmalling (Søren Malling)]

This is one of 3 tasks in a combination to create a Flow Light

This is the “mother” funding request for the other three funding requests regarding Flow Light

The idea and purpose is to split the doctrine dependency and integrations into a number of smaller packages covering those parts.

Today we have doctrine dependencies inside some validators, routing via DynamicRoutePart and inside Package.php of Neos.Flow.

The goal is to move these integrations out and create a Persistence package that reintroduce the Persistence possibilities, but not having it as a dependency removing a number of required installationen packages (see this original post with some background information Could we build a version of Flow without doctrine orm / database requirement)

Should everything work just like before and as “we are used to”. Oh yes

This will be possible by using the possibilities of the object management and Objects.yaml to change the implementation depending on the installed packages.

The future work has been splitted into other separate tasks

Funding request: [Flow Light] Routing: Move ObjectPathMapping to a cache

This is one of 3 tasks in a combination to create a Flow Light Since there is a direct dependency on the Doctrine persistence layer inside the DynamicRoutePartValue this funding request will only make sense if the Split Doctrine Dependency from Neos.Flow is accepted` What is the purpose of this project? To remove the need of a database table to store routing information and instead move this to a cache. Moving this storage from a database to a cache is a step on the way to create a Flow Li…

Funding request: [Flow Light] Resource management: Create a resource storage that doesn’t need database

This is one of 3 tasks in a combination to create a Flow Light Since there is a direct dependency on the Doctrine persistence layer inside the current Resource Management this funding request will only make sense if the Split Doctrine Dependency from Neos.Flow is accepted` What is the purpose of this project? To add a new resource handling mechanism, that can work without the database dependency. This will move all work around resources away from “PersistentResource” as a entity, but still…

To cover some of the followup tasks and work.

This project also covers

• Move all database migrations to the corresponding packages
• Move all entities inside Neos.Flow to corresponding packages
• Move tests to corresponding packages

This is quiet a task… Let’s be honest.

Yes, it is. And there are a lot of holes we can fall into along the way - but we can also decide to get out of all the holes again.

Will it break something…

There will be some renaming of namespaces and inherited classes. While the existing interfaces should stay the say, the classes will move around.

This can be handled in Flow 7 with “empty” classes extending the new classes and then removed in Flow 8 (or 9, or 10) - then we have a deprecation period. And that can help integrators. And us.

This either takes some research or “just dive in”…

I’m more of the “dive in” kind of person. I’ve been diving into this subject a number of times and been splitting parts up. Some with more luck than others. But always in my own little universe and not showing or telling others of the progres.

I’ve splitted most parts of the persistence of objectpathmapping into a cache. Splitted parts of the security package into it’s own packages to make the Neos.Flow package lighter.

This is also a community effort for creating a “first choice” framework

I don’t think this should be a one man job, and when I look at the time it will take (ESTIMATE!) a “task force” of 2 or 3 people will greatly benefit to help each other up and “to it” to reach the goal.

So, how much is it?

I will be saying the estimate of this task is 150 hours.

So is this including the others funding requests that you have created.

No - they are actually depending on this. So it’s the other way around IMO The other funding requests makes less sense if this task is not handled first.

So is this settled in stone

No, not at all. All feedback, ideas, worries etc. should and will be listened to. After all, it’s not “mine” - it’s ours.

We have a CMS platform running on this framework - so this is not the plan to leave anything worse than before.

But there is also many more use-cases for Flow that we can use it for, by creating a lighter version

So the request for funding money

Not knowing the hourly rate this is calculated with a hourly rate of €100

150 hours * €100 = €15000

[aberl (Alexander Berl)]

Hey, thanks for this funding request!

IMO The other funding requests makes less sense if this task is not handled first.

I do think, we can indeed start with the routing/objectpathmapping part, even without having the Framework fully decoupled from the persistence layer. I even do think, that this would make more sense to do first, because that way we already reduce the direct coupling, because routing then only depends on Caching package, so we have one less dependency path to deal with.
It would also be much easier to get a small funding granted first, that already goes in the right direction.