Version 3 concept

[Padam87]

Hello Everyone,

Yesterday I had a couple of emails with @AkenRoberts, we talked about the future of this project.

As you know, the package is very hard to maintain, and would desperately need refreshment.

I'm on the side of a complete rewrite, @AkenRoberts is also leaning towards that.
1 package per component and a metapackage as the main package is also very appealing.

I created a concept, I would like to ask your opinion about it.

---

https://github.com/Padam87/sluggable2

this repo currently contains common files, a sluggable extension, and it is just for demo / POC purposes

I started by extending the metadata factory
https://github.com/Padam87/sluggable2/blob/master/src/Metadata/ExtendedClassMetadataFactory.php

and created an extended metadata class to hold our data
https://github.com/Padam87/sluggable2/blob/master/src/Metadata/ExtendedClassMetadata.php

extended the annotation driver to allow extensions to hook up to it
https://github.com/Padam87/sluggable2/blob/master/src/Metadata/Driver/AnnotationDriver.php

sluggable extension
https://github.com/Padam87/sluggable2/blob/master/src/Metadata/Driver/SluggableDriverExtension.php

and the listener accessing the data from the extended metadata class
https://github.com/Padam87/sluggable2/blob/master/src/Listener/SluggableListener.php

---

As you know, doctrine 3 is also on the way, so I had a short chat with @guilhermeblanco about the long-term viability of this concept. He said it may need some adjustments once V3 is out, but it should hold up.

[danielchodusov]

Hi,

some time ago I already split Tree and Common package from this repository, since this is the only one package I use very often and only one package from this suite.

Would you consider to split more packages and move it towards this namespace? I'm ready to maintain the tree repository and help with others.

https://github.com/DoctrineExtensions/Tree

[stephanvierkant]

Hi @Padam87, thank you for this initiative! I agree this library is very hard to maintain.

What about pairing with other libraries?

I see KnpLabs/DoctrineBehaviors is looking for maintainers too. See KnpLabs/DoctrineBehaviors#399, KnpLabs/DoctrineBehaviors#409

[Padam87]

@danielchodusov A split is definitely the way to go, but I'm thinking about a complete rewrite.

The whole lib is over-engineered, and could be much simpler if we limit the scope to ORM, and annotation mapping.

Given that covers 80-90% of needs, and our maintenance capacity is very limited, I think it is the right choice.

I would love to have a dedicated maintainer for each extension. It would probably mean less burnouts, so longer tenures for everyone.

Tree is the hardest. Are you up for a complete rewrite?

I too have created an org for this: https://github.com/doctrine-extensions :)

[Padam87]

@stephanvierkant Definitely a good idea, we need everyone willing to contribute.

I use the translatable part of the KNP package. I think it is better than this.

[Padam87]

Soooo

https://github.com/doctrine-extensions/doctrine-extensions
This is main repo with a subtree split (Oh yeah, forgot to add... work should be done in a monorepo)

https://github.com/doctrine-extensions/common
https://github.com/doctrine-extensions/sluggable

We should keep it informal until it is at least usable.

Who wants in?

(My time is very limited, but I can set aside an hour a few days a week - it should be enough to maintain an extension)

[danielchodusov]

@Padam87 Hi sure I can analyse the code and find out what needs to be fixed, rewritten and what code can be left as it is. In my work I already did some cleanup and moved it to better coding standard. I will use Tree in my company upcoming project soon, so I'm up to help and maintain it since I will need to use it anyway :)

And as @stephanvierkant mentioned It would be also good idea to implement KNP's version of Translatable, I like the approach more better.

[danielchodusov]

@Padam87 would you like to move working to https://github.com/DoctrineExtensions? Since this tree package is listed already in packagist (https://packagist.org/packages/doctrine-extensions/tree) I think it make more sense to continue working there. I would be happy to set you as the maintainer and invite more people :)

[Padam87]

@danielchodusov No thanks, I have already created one. https://github.com/doctrine-extensions/doctrine-extensions

I'm set on a rewrite, that is what I will do. If it is supported, it should be able to grow, and eventually replace existing libs. If not supported it will fail. I'm okay with that.

[AkenRoberts]

I'm really happy to see some new dedication to this topic. After chatting with @Padam87 I thought I'd be on my own for a bit! 😄

I'm +1 for the fresh start. Let's take inspiration from the current extensions + KNP's behaviors and create a new set of modern packages.

I'll be over at doctrine-extensions if you need me!

[Padam87]

I think I will use today to get things into shape. Write some tests, extend the commons. I think after that work can start on the extensions.

A simple one, like the timestampable could even be started now.

[Padam87]

https://github.com/doctrine-extensions/doctrine-extensions/blob/master/src/Extension/Sluggable/Tests/Functional/SluggableTest.php

All the functional tests pass for sluggable, so I think it is decision time. Anyone willing to go over the existing codebase and check for conceptual issues?

[svycka]

Do I understand correctly? you want to drop support for current extensions and will create new ones? If this will be a complete rewrite and without migration plan, I don't know how many users or when will be able to migrate.
maybe it would be possible to just split repository without any big BC breaks(not sure if this is even possible)? And then update extensions one at a time maybe with migration plan or something.
I understand this is a lot more work and for an open source project may be too much but users then more likely will upgrade than replacing with a completely new library.

[stephanvierkant]

I think this 'new' library can only succeed if we get both communities together. Both Atlantic18 and KnpLabs have a problem with maintainability and that creates an opportunity to unite.

But if we create a new version without a migration plan and without working together, this might happen:

[Padam87]

@stephanvierkant This is unavoidable unfortunately. We can set up a migration plan, but there will be 3 libs...

I'm not saying we shouldn't, just stating there will be 3 anyway for a while.

Are you interested in contributing?

[andrewtch]

Just a couple questions:

1. is the 3.0 branch for Doctrine 3.x only?
2. what the support / BC strategy?
3. is there a common structure for a component (e.g. I see you have test entities out of test namespace, that would mess things up etc)
4. what are short/long term goals?

[Padam87]

@andrewtch

1, No 3.0 branch, but a separate org. Doctrine 2 is supported, doctrine 3 will be supported

2, support: we would like 1 dedicated maintainer per extension instead of 1 for the whole lib. Right now there are 2 libs with very little maintenance. It is too much to ask people for all their free time. Maybe they would be more willing to just maintain one.

BC: No BC, but a migration guide should be written for all components

3, Yes. Check the sluggable.
https://github.com/doctrine-extensions/doctrine-extensions/tree/master/src/Extension/Sluggable
An annotation and a driver extension (Mapping dir) is required for all extensions. This will ensure the mapping is read and accessible. A listener and (if necessary) some extra classes can take care of the rest.

e.g. I see you have test entities out of test namespace, that would mess things up etc

Not sure what do you mean by that. Test entities are placed in {{extension_root}}/Tests/Fixtures/Entity

4, Short: find people willing to take on an extension. Everyone can contribute to multiple extensions, but should only be responsible for 1.

Long: A new extension library composed by separate extensions.
https://github.com/doctrine-extensions -> already separated, but work is done in the main monorepo.

[Padam87]

@andrewtch doctrine-extensions/doctrine-extensions#3

This is an example for a new extension. Anyone can do it, so even 3rd party extensions can use the framework.

[AkenRoberts]

Our goals are outlined in the new repo. Right now we need to focus on two things:

1. Finding people who are interested in contributing to extensions
2. Building extensions

Without a new product, there is no concern for backwards or future compatibility, migrations, etc.

[Padam87]

Exactly like @AkenRoberts said. The success / failure of this project depends on the willingness to help.

With the new concept, If you have ever created a doctrine listener, you can create an extension - That is why it is great.

Annotation, DriverExtension, Listener, Tests - 3 classes and their tests are not too much to handle.
Tree, translatable and audiatable are obviously more difficult.

Even if you are not totally convinced... contribute one of the simple extensions, and tell us your opinion. I believe the flow will start once you start coding. Even if it isn't, a few hours is not too much to give..

[l3pp4rd]

by the way guys, I just wanted to suggest closing all open issues and pull requests to make a cleaner start. 90% of it are already irrelevant and ones which were relevant - will emerge again soon.

[andrewtch]

@Padam87 , not everything ) I'd explicitly ask for plans on Translatable / Tree if possible. There are only you and @AkenRoberts currently, yes?

[Padam87]

Yes, and that is the main problem. This is not a 2 person project, more like a 5-10 person project.

Translatable / Tree : Have you ever used KNP's translatable? It makes life much easier. I think I had a project with tree and KNP translatable some years ago, I will try to dig it up, and show what I'm thinking.

[Padam87]

@andrewtch https://gist.github.com/Padam87/a013b0d42f523096b35297ba8d2a5eec

In this example the Category is a tree, and it has translatable names (CategoryTranslation). The localized name is also slugged.

It even has countrySettings, which is my own custom extension, does the same thing translatable does, but for country instead of locale.

[andrewtch]

@Padam87 , KNP trasnlatable lacks SQL walkers which is very needed feature when you really need to join tons of entities (and care about performance).

E.g. in one of the calls in one of the projects I need to serialize whole category tree of ~9000 entities, with translations and slugs. Gedmo does it with one SQL.

[andrewtch]

I especially point on this code: https://github.com/Atlantic18/DoctrineExtensions/blob/v2.4.x/lib/Gedmo/Tree/Entity/Repository/NestedTreeRepository.php which is the main reason to stay with Gedmo )

[Padam87]

@andrewtch
The tree is from here, only the translatable is from KNP. They work together way better than the gedmo translatable + gedmo tree.
You can have the same nested tree repo.

I love when devs are trying to pick apart something that is not even built yet. Good way to get nothing done.

[andrewtch]

@Padam87 , I'm not trying to pick something here. I'm more trying to understand if I am able to upgrade the current projects to the new library, which would mean at least BC / compatibility layer (as you can transition your Doctrine code from 2.6 to 3.0 with minor changes I'd expect the same for dependent libraries).

[Padam87]

@andrewtch I understand that you have good intensions, but please respect that these decisions you are aking me to make cannot be made by 1 person (me), without even knowing which implementation we are chosing, or even writing a single line of tree extension code.

This is not the right way to do this. These decisions should be deferred.

The right way to do is is: "I'm falamiar with the tree extension, I know the pitfalls, I will help."

These kind of questions are weeks or months away, depending on the support we get. This is what this project depends on. But so far, everyone talks, no one works. I spent the time I had for this today arguing instead of unit testing timestampable. :) This is not helpful.

[andrewtch]

Ok, willing to help with Tree and Translatable if 1) there is compatibility layer with current version 2) the repository API stays 3) the current tests somehow run.

Can we try it this way?

[AkenRoberts]

@andrewtch When we say that this library is over-engineered we mean the implementation(s), not the extensions / features. Tree is an incredibly useful extension, one that I'm heavily interested in for my projects as well. I intend to put the best of my abilities into a Tree extension in our new package.

As far as how much I can support this package, I don't plan on doing any significant development. However, I will be trying to get all the issues and PRs under control, will continue to respond to any new ones, get some basic code updates and styles going, things of that nature. Just attempting to get it modernized so that if anyone does want to put significant time into it, it will be in a better place to do so.

Personally, I'm not interested in backwards compatibility with existing extensions. Sometimes it might happen, as we'll be using them as reference. But with a new package, new namespaces, new bundles/configuration, you're going to have migration steps regardless. It's a perfect time to build things the way we think is best, whether that's matching old APIs or not.

[Padam87]

@andrewtch
I think the tree is okay the way it is. I don't know about compatibility layer, leaning toward a migration guide.

The translatable should be discussed. I'm in favor of KNP's, as it much cleaner, and has no interaction issues with other extensions. I can be convinced otherwise though.

[andrewtch]

@Padam87 now we are talking :)

When we talk about compatibility, I talk more about a polyfill. Haven't looked on your implementaiton yet but I suppose for sluggable this is just couple of lines.

For compatibility that's either a polyfill or Rector - basically whatever that allows to transition current projects (in one of the projects I have 60 translatable entities) without major rewrite. Again, I'm not saying that you doing it wrong, I am talking about adoption - people are unlikely to move to your library if it requires thousands of hours of rewrite and database transition.

For Translatable - I don't give a damn how it works when 1) I can transition current entities in projects to new library 2) I can port TranslationWalker from Gedmo somehow.

Guys, what's the best way to talk with you three apart of Github comments?

[Padam87]

Currently we don't have a chat or anything, but we could start a slack.

I have a question about the TranslationWalker... I'm not too familiar with this translations component, dropped it very long ago.

I think with KNP's, we might not even need the walker. Every translatable entity has it's own translation entity and DB table, so I have always used a simple join.

Is that the main concern here?

[andrewtch]

I recall creating #doctrineextensions channel in symfony Slack long time ago - are you in? )

[TomasVotruba]

Just FYI, https://github.com/KnpLabs/DoctrineBehaviors is up and running (last 2 days :), stay tuned

[AkenRoberts]

Best of luck @TomasVotruba! I'm not sure how far I'll actually get with the extensions here. I always thought it was weird that there were two seemingly identical extensions. Very different implementations, though.

[TomasVotruba]

Just going through the disccusion now slowly. There are many great ideas like

• monorepo
• split package per behavior

But it seems all the hype was around March 18-21. I'd expect to have this done now after 9 month. What happened?

[maxhelias]

@AkenRoberts, @TomasVotruba we can join forces in the organization: https://github.com/doctrine-extensions and finished what was started ?

[TomasVotruba]

I'm currently focused on KnpLabs/DoctrineBehaviors#442 and don't want to split my attention now. I don't use this package, so can't really help

What happened with the hype?

[maxhelias]

I don't know, I arrived a few days ago

[AkenRoberts]

I'd expect to have this done now after 9 month. What happened?

Ideas are always plentiful. Execution is hard. Effort that just wasn't put forth by myself during the last 9 months. Maybe because I got paralyzed between trying to decide what was better - starting new or upgrading this behemoth. Along with the usual life things taking up a considerable amount of time. I don't have a pressing need for Extensions at the moment, so maintaining it becomes more about incremental steps instead of major overhauls.

[Padam87]

Pretty much the same as @AkenRoberts for me. I'm using my own stuff for this. It is jury-rigged, but it works.

Plus it was a huge bummer for me to deal with all the pushback we got. People were bellyaching about stuff that should have not entered into conversation for the first few months.

Plenty people complained, no one offered help. I told everyone this for the start... If I had to do this alone, I would rather not do it at all.

[svycka]

@AkenRoberts maybe you could create a task or something instead of doing yourself and maybe we could help you with something. Because now I don't know how can I help and I guess more people will help too. At least I don't know what you already did and what needs to be done. I don't even know how we decided to update with BC break or without. Also, some kind of plan would be good.

[AkenRoberts]

Great idea. I'll do my best to put together a plan of action this weekend, outlining what I think is necessary for a 3.0 release.

Closing this issue now, since nothing new has come of it and a new concept isn't going to be taking over any time soon.

[TomasVotruba]

Ideas are always plentiful. Execution is hard.

Not really. Depends on the plan quality and motivation.

I finished some work and I wanted to share with you, as our goal is simple - help Doctrine & Symfony users work with *able behaviors in their entities without any maintenance/configuration.

Luckily there were Christmas, so I had some time to finish DoctrineBehaviors with Symfony 5 support and after 5 dev releases I released 2.0 stable:

• Doctrine Behaviors 2.0 - Reloaded

For those who want to use Symfony 4/5 features that Knp already provides and are stuck on gedmo for months against their will, there is also migration path.

I hope this helps Doctrine & Symfony 5 users to enjoy behaviors with plug & play effect 🙏