KnpRadBundle icon indicating copy to clipboard operation
KnpRadBundle copied to clipboard

split KnpRadBundle into smaller components

Open thkoch2001 opened this issue 11 years ago • 11 comments
trafficstars

There are a lot of nice ideas in KnpRadBundle and I'd like to try them out for an existing project. But I hesitate to include such a large bundle that comes with so many new ideas. Maybe I don't want to make all of them available in the project?

It would also help in learning if we could include smaller KnpRadBundle Subcomponents one by one.

thkoch2001 avatar Sep 26 '14 07:09 thkoch2001

hello! even though I also think knprad bundle is an aggregate of unrelated stuff, and it would beneficiate a split into many components, it would harden the day to day maintenance [1] and complexify release. That's not something i'd like to do right now, but if someone is motivated to do so, why not! (1: maybe not, small libs are easier to maintain)

Otherwise, it's still possible to require this bundle, but not register it in the AppKernel. You would then manually enable some of its features (registering only services you want to). Thanks for pointing that out!

docteurklein avatar Sep 28 '14 18:09 docteurklein

@docteurklein agree that it will be painfull to maintain those "many" components. But for me this is a great idea!

We can separate all the rad components and install them only when it's needed. Otherwise, we can also enhance the documentation for each rad component. Because actually, the documentation is like dark matter ... we don't see it.

I like the idea to separate the rad into plural bundles or components and i am motivated if people want to follow me on this ? Maybe, @PedroTroller @Einenlum @Shivoham or others ?

Djeg avatar Dec 01 '14 09:12 Djeg

yes-gif 1

PedroTroller avatar Dec 01 '14 10:12 PedroTroller

rainbow

docteurklein avatar Dec 01 '14 10:12 docteurklein

yes

docteurklein avatar Dec 01 '14 10:12 docteurklein

We have to take care of BC somehow. A simple file split conserving the same namespace would allow this, since autoloading would take care of reassembling the sparse classes.

docteurklein avatar Dec 01 '14 10:12 docteurklein

and here we start to see the problem of having a "Bundle" suffix :)

docteurklein avatar Dec 01 '14 10:12 docteurklein

I vote for no Bundle suffix. We need to decouple components from symfony2, and honestly, each time i see a Bundle prefix it's like a big facepalm: facepalm

Djeg avatar Dec 01 '14 12:12 Djeg

if you vot for no bundle suffix, you'll have to find a solution to maintain BC. Or maybe we simply don't care about preserving class naming, since the bundle is just about gluing all this iside the sf container :)

docteurklein avatar Dec 01 '14 12:12 docteurklein

yeah, let's do this!

docteurklein avatar Dec 01 '14 12:12 docteurklein

no bundles — no problems

cursedcoder avatar Dec 02 '14 01:12 cursedcoder