in an effort to clean things up I would like to discuss subpackages.
IMHO this is a bad concept in itself, as composer offers all the heavy lifting of different packages and you should always go for that if you need to separate modules/domains/code.
Subpackages have never gotten a lot of attention and I feel they are unwieldy to use, rarely useful and add a bagage of code to several parts of Flow that relatively unnecessary. Also I think they work for a couple of use cases but not for others because they are not implemented across board for everything in Flow.
All in all my suggestion is to deprecate the concept, move away from it and remove it in the (next-) next major (so Flow 5).
I always found this concept clumsy. Flat is usually better than nested. from me to the idea, but I don’t know of all of the technical implications in the Flow universe.
I always use plugin-packages in the Vendor.Site.SpecialIsolatedTopic Namespace. That way the code is nicely bundled with fusion-code and configurations. So i see no need for subpackages.
Sub packages can come handy, but if I’d had to decide today, I wouldn’t introduce them again.
I support the idea to not promote using sub packages or even mentioning in the documentation that this is an exotic feature and you should look for alternatives. But if it doesn’t cost us a lot of maintenance, I’d just leave it in place.
The first one has the psr-0 autoload path (and PHP class namespace prefix) Netlogix\JsonApiOrg.
The others have the prs-0 autoload paths (and PHP class namespace prefixes) Netlogix\JsonApiOrg\AnnotationGenerics , Netlogix\JsonApiOrg\Consumer and Netlogix\JsonApiOrg\ExampleData .
But all are clearly different composer packages and share only psr-0 paths and namespaces prefix “by accident”.
Actually the concept is not really explained in the documentation but only hinted at.
The routing chapter (ever wondered about the @subpackage default you set in your routes) and the MVC chapter say something about subpackages but never actually explain it.
So no what you do is not a subpackage in the sense of what I mean.
Regarding the current discussion about the directory structure in CQRS / ES applications: in one project I moved action controllers, CLI commands and other infrastructural code into a folder / namespace “Application” of my package. Because, all the domain-related code lives in a “Domain” namespace, why should the Action Controller be on the top level? Additionally, it was very confusing that there was a namespace “Command” on the top level (for CLI commands) and a “Command” namespace within the Domain folder structure (for CQRS commands).
This structure (with the Application folder) currently can only be realized by using the sub packages feature in Flow. But that doesn’t mean that this is the only way.
If we come to the conclusion that Action Controllers, CLI Commands and all that should rather live in “Application”, we could easily add support for that in Flow. It would be a new convention which we propagate, and still allow the old convention. It does not mean that we need to stick to the general concept of sub packages (although … it proves the point that they were helpful in my specific case where I wanted to play around with namespaces …).
Sure, and I agree to the directory/namespace structure. I think subpackages were rather a technical clutch to do this in the opinionated world of Flow though.
I would really like to get rid of it and replace it by something more lightweight that basically only affects were controllers are found (it’s not much more anyway).
Thank you for clearing this up. This means I’m right about subpackages being “the other thing” I never really got into.
Then I’m all in for not using subpackages any longer, especially since using different composer packages that just share a common directory structure feels way better in terms of plug-in replaceabilit anyway :).
Not sure, the concept does eliminate some overhead that separate packages bring like composer manifest. It’s nice to use for bounded context for the same area e.g.
Anyway could live without it of course, but unsure if it’s really worth getting rid of since it potentially can enforce a major refactoring of projects out there, which the reasons mentioned here really don’t justify IMO.
So would prefer keeping it, but migrate core code away as part of the package split effort and keep it out of the documentation.
I think there is some cost of supporting this concept and it makes many things like routing harder to understand. I had many cases where a subpackage in Neos had to be specified as "" when creating URIs to prevent issues where a subpackage “shined through”.
I think this is one feature which bloats the codebase and which needs to be pulled supported through many different layers. So in regard for a future major Flow version I’d support getting rid of it.
Just a quick note to explain that behavior:
As you know the current package/subpackage/controller is assumed if you don’t specify it in a uri/link ViewHelper (or in a redirect() call within the ActionController).
That’s why you need to specify the subpackage if your target action is in a different one (including none).
We improved the situation slightly by “resetting” the subpackage if you specify the package, so instead of subpackage: '' you could also write package: 'Your.Package' but that probably doesn’t improve it notably
It’s not too bad actually, just very few places in Flow. But I agree that it confuses people and I’d also be in favor of steering away from the concept…
I like Roberts idea:
But it might be “over the top” to introduce this new convention for every package…
from me to the idea, but I don’t know of all of the technical implications in the Flow universe.
