Are getPackageName and getPackageDescription necessary?
Permalink
Whenever building blocks or package we always have the methods for returning the package name and description.
But those methods are available from the parent class, and the parent class returns the $pkgName and $pkgDescription variables already translated.
So is it actually necessary to even include these two methods in a class already extending the Package class, where these methods are initially defined? Why even override them when we can simply declare the variable names instead?
Seems like this is sufficient enough within a package controller rather than reclaring the getPackageName and getPackageDescription methods?
Or am I missing something here?
But those methods are available from the parent class, and the parent class returns the $pkgName and $pkgDescription variables already translated.
So is it actually necessary to even include these two methods in a class already extending the Package class, where these methods are initially defined? Why even override them when we can simply declare the variable names instead?
$pkgName = "My Awesome Package" $pkgDescription = "My awesome package description"
Or am I missing something here?
Thanks for clarifying. Another benefit to using the methods is so you can call it from another class. For example, if the block within a package shares the same name and description, you could pull it from the package controller only when the method exists instead of having the same text in two places.
For single block packages, for the primary block in a multi-block package and also for the primary dashboard page name, I often pull the name and description from the package controller. DRY.
How do you normally pull the name from package controller? I was doing it like so: and then in the theme page_view (or block controller if that was the case)
use Concrete\Package\MyTheme\Controller as MyTheme;
public function getThemeName() { return MyTheme::getPackageName(); } public function getThemeDescription() { return MyTheme::getPackageDescription(); }
I haven't used that exactly, but generally along those lines.
The properties are there by legacy and are deprecated. Parent methods provide a fallback so packages coded without the methods don't break a site when the core startup loads all package controllers.