Single bundle application wide -??

[keymaster]

Even application specific code can become too varied to comfortably sit together in a single bundle.

Please consider allowing multiple bundles according to application needs.

Otherwise you may be limiting this great bundle's applicability to small projects only.

[everzet]

1. Give me an example of application code, that became too varied to comfortably sit together
2. You still can create/enabled/use full-featured Symfony2 bundles in your src folder. But you could have only one simplified app bundle.

[keymaster]

Is the restriction to a single simplified bundle dictated by a technical limitation - ie there are RAD features which simply cannot be implemented when there is more than one simplified bundle?

Or,

Is the restriction a projection of your development philosophy - ie. you don't believe people should be breaking up their app into multiple bundles?

[everzet]

both.

So, what's your example? I can show you that you can maintain cleanly even huuuge project within single app bundle.

[keymaster]

Well, consider a large, custom ecommerce site:

users, groups, admin panel, articles, attachments, breadcrumbs, catalog, comments, config management, debugging tools, search/filters, media management, seo, sitemaps, cart, orders, checkout, coupons, partners, payments, products, shipping, help desk, chat, third party interfaces, REST api's, theming, .....

Are you seriously proposing stuffing everything into one bundle?

[stof]

You can have many subnamespaces in the bundle to organize your code.

And btw, such e-commerce site site should probably reuse existing shared bundles as there is already bundles aimed at e-commerce :)

[everzet]

@keymaster And what's wrong with it?

src/ECommerce/
    Controller/
        Admin/
            UsersPanelController.php  <-- class ECommerce\Controller\Admin\UsersPanelController
            SitesPanelController.php
        Frontend/
            DashboardController.php
        Api/
            UsersController.php
            SitesController.php
    Entity/
        User.php
        Site.php
    Resources/
        config/
            services.yml  <-- autoloaded. Requires other service configurations (api/services.yml, admin/services.yml)
            routing.yml  <-- autoloaded. Requires other routing configurations (api/routing.yml, admin/routing.yml)
            api/
                services.yml
                routing.yml
            admin/
                services.yml
                routing.yml
        views/
            Admin/
                UsersPanel/
                    index.html.twig  <-- template automatically used by Admin\UsersPanelController::index()
                layout.html.twig  <-- layout of admin section
            Frontend/
                Dashboard/
                    index.html.twig  <-- template automatically used by Frontend\DashboardController::index()
                layout.html.twig  <-- layout of frontend site section
            layout.html.twig  <-- general page layout

I see no problems. Code is coupled anyway, as you're still talking about single application, but lives in one convenient place and have the same reusability/optimization options, that you have with multiple bundles - you only not required to register and configure them all - only single one.

And as @stof said, you still can use 3rd-party bundles without problems.

[everzet]

Clean code is not about putting everything into separate bundles ;-)

[lsmith77]

I agree that a single Bundle for all application specific code works just fine as anything else should probably go into the vendor/bundles dir anyway. that being said .. once you start organizing things into subnamespaces, then i wonder what you are really gaining for not using multiple Bundles?

aka one of your arguments was that for example the RAD generators do not need to get a bundle name passed to them. but well if you want to organize things into subnamespaces, they would then need to get a subnamespace parameter.

[everzet]

@lsmith77

./console rad:generate:controller Admin/Users:index vs. ./console rad:generate:controller @AcmeSomeBundle:Admin/Users:index --path=src

[lsmith77]

if you use multiple bundles, you will likely not need to organize things into subnamespaces plus if you then at some point need to split out some code because you are creating a new application, you don't need to do a gigantic refactoring because everything is already organized in Bundles.

in short this one bundle approach is only really helpful for very simple use cases but can lead to additional work down the road.

so imho the better approach would be to simply add a wrapper around the SensioGeneratorBundle to allow setting a default bundle name to make life easier for the simple use case this solution is trying to cover

[everzet]

@lsmith77

1. Our generators started as wrappers around SensioGeneratorBundle. But the problem is, with this stuff, generators becomes too complex. Those generators are over-engineered, imo :-/
2. Yes, you need to put effort into making code shareable. Always! The one key difference with "everything is a bundle" approach is that you're putting this effort before going in need to make code shareable anyway. It's like putting 30% of job just for the sake of share-ability, that you most like will not need. Our approach instead is to say that your app code isn't shareable by default, so it's much faster to develop (RAD), but if you need to make some part of app shareable - then and only then put effort into making it a bundle.

[everzet]

@lsmith77 and i might be wrong, but putting controller in new subnamespace inside single app bundle is much-much-much simpler and faster than creating same controller inside new separate bundle, then initializing this bundle, then creating it's routing.yml, then importing this routing.yml ;-)

[lsmith77]

My point is:

• You can use a single Bundle today already
• At some point however you might feel like you are overburdening your Bundle, so you either create another bundle or start using subnamespaces to better organize the code
• Using subnamespaces is slightly easier to do, however thanks to generators creating a new Bundle is also very easy
• Using subnamespaces however as the disadvantage that if you want to share some of your logical code units with other apps will require then creating a new Bundle

So to me using subnamespaces doesn't save much work, it just introduces yet another concept that can cause additional work down the road.

[everzet]

@lsmith77 every feature or rule inside KnpRadBundle is based on our long Symfony2 development experience. In all our projects (and we have a lot of them), only 5-8% of code becomes shareable bundles. Why putting so much effort for every piece of application code if you'll need it only in 5-8% of cases?

[lsmith77]

Well in my experience it happens fairly often and also I don't think that creating a new Bundle is a lot of work and I even define all my controllers as services which I assume you guys don't do, so creating a new Bundle should be even easier for you.

Anyway, just as controllers as services or not, I guess people have different tastes. They also do different kind of applications. Most of my real life Symfony2 work has revolved around 2 large applications that each have multiple kernels deployed to multiple servers.

Now if you do a lot of work creating fairly simple projects that range from 2-10 controllers and that last maybe 2 months, then your perception might of course be different.

However this is also why I said that to me, this bundle doesn't solve a problem I have. Which in turn should not mean that you need to try and make it work for my use cases if that means that it will be less useful for you.

[everzet]

@lsmith77 yeah, we're not trying to solve any problem out there. This bundle helps us to solve problems, that we have in our daylife and will help other people with same approaches and development flows.

But it's not intended to be universal solution for every project out there - it's just another distribution of already awesome framework ;-)

[keymaster]

I think it is inevitable, as the app grows, that clumps of functionality within the bundle will tend to become more tightly coupled within itself than to the rest of the bundle, and the effort to refactor will outweigh the initial gains. I'm not referring to reusable stuff, just functional groupings within the app specific stuff.

I agree with @lsmith77, unless the single bundle thing is removed, I also don't see this as being especially useful for anything more than simple apps.

On the other hand, the base controller, autoloads, default views, code generators, are all tremendous contributions.

Would love to see those released as a separate bundle without the "single bundle" thing :-)