AppName in dependency injection

rawtaz · March 2, 2023, 4:01pm

So I read Dependency injection — Nextcloud latest Developer Manual latest documentation and it lists AppName as one of the predefined core services. But it also states in a note box that:

$AppName is resolved because the container registered a parameter under the key ‘AppName’ which will return the app id. The lookup is case sensitive so while $AppName will work correctly, using $appName as a constructor parameter will fail.

Now, if one pokes around in the Nextcloud apps’ source code, there is uncountable numbers of occurrences of string $appName in various constructors, as opposed to string $AppName as the documentation seems to suggest one should be using (and also saying is the only thing that works).

So, why does string $appName seemingly work just fine, despite the documentation saying this should not be the case? And also, why is string $appName used instead of the apparently correct string $AppName? Is it for some reason recommended to use string $appName instead of string $AppName?

On a related note, I might as well ask; Is there any reason to use one of the above methods to get the app ID into e.g. a controller, instead of just importing the app’s Application class and referencing Application::APP_ID? I don’t really see the point of adding cruft to the constructors and a property to the class, instead of just having one single import and then getting access to the app ID right away.

kesselb · March 2, 2023, 4:28pm

github.com/nextcloud/server

Clean up and deprecate app container parameter aliases

nextcloud:master ← nextcloud:chore/deprecate-app-container-aliases

opened 06:47PM - 02 Nov 22 UTC

ChristophWurst

+9 -6

An app can have app name, web root and user ID injected. Those parameters are re…gistered in pascal case with a camel case alias. Our coding styles suggest camel case, so it always felt weird that we inject `$UserId` in so many places and then assign it to a `private $userId` (lowering the first letter). Now I found out that we actually even have aliases for the lower case variant and they just make more sense. So with this change I'm flipping the service registration. The lower case ones (camel case) are the intended ones, upper (pascal case) are the aliases. In the same step I'm deprecating the aliases so we can remove them one day. This is a micro optimization because it's one registration less on every app container. Documentation: https://github.com/nextcloud/documentation/pull/9285

tl;dr use $appName.

rawtaz · March 2, 2023, 4:41pm

Spot on answer to the first set of questions Regarding why people we using the camel case one instead of the pascal case one everywhere, I guess it’s just because what came natural to them and it worked (in contrast to what the documentation said should work).

The other question is still unclear though; Is there any reason to use one of the above methods to get the app ID into e.g. a controller, instead of just importing the app’s Application class and referencing Application::APP_ID ? I don’t really see the point of adding cruft to the constructors and a property to the class, instead of just having one single import and then getting access to the app ID right away.