what is going on with global $c ?
Permalink 1 user found helpful
What is going on with the extensive use of "global $c" and "global $u", to get at the page and user objects, used throughout the code?
This use of "global $c" appears to be official too, as both Franz and Andrew have used it in numerous code examples on this site.
Surely this goes against a number of important coding principles? Should it not only be accessible by the use of calls such as $this->getCollectionObject() - which appears to return the same thing.
The moment I saw this code I became nervous about the code-base (which I have been assessing for possible use by our team) which I had previously been impressed with.
Can someone fill me on on the thinking here?
This use of "global $c" appears to be official too, as both Franz and Andrew have used it in numerous code examples on this site.
Surely this goes against a number of important coding principles? Should it not only be accessible by the use of calls such as $this->getCollectionObject() - which appears to return the same thing.
The moment I saw this code I became nervous about the code-base (which I have been assessing for possible use by our team) which I had previously been impressed with.
Can someone fill me on on the thinking here?
Incidentally, another reason for this is that, as concrete has evolved over several years, our API has been in flux, and some of the more elegant calls like Object::getCollectionObject() did not appear in previous versions of concrete5 in all contexts where global $c is used.
In the future, we will likely be slowly phasing out these calls for
$u = new User();
and the static
Request::getPage();
(which doesn't currently exist). Code re-use and safety is definitely on our minds, which I think you can see when you check out the block and collection/page/controller models.
In the future, we will likely be slowly phasing out these calls for
$u = new User();
and the static
Request::getPage();
(which doesn't currently exist). Code re-use and safety is definitely on our minds, which I think you can see when you check out the block and collection/page/controller models.
user global function is also used in drupal. just that have the function named and documented properly.
ie, use $c->getTitle() instead of $c->getCollectionName(), it's not funny how many times i need to refer back to other theme when i need the title on a theme
ie, use $c->getTitle() instead of $c->getCollectionName(), it's not funny how many times i need to refer back to other theme when i need the title on a theme
Is it really the same in drupal - where the keyword "global" is used in order to grab a variable outside the current scope? Your example seems very different from the one under discussion.
The problem here is that concrete5's $c page object is unprotected. At any point in the code somebody, in a contributed block for example, could accidentally set the actual global $c object to null, which would render it useless for any subsequent access and pull down the app. This should not be possible. This is why global variables are nearly always bad - and it's what OOP was designed to prevent.
The problem here is that concrete5's $c page object is unprotected. At any point in the code somebody, in a contributed block for example, could accidentally set the actual global $c object to null, which would render it useless for any subsequent access and pull down the app. This should not be possible. This is why global variables are nearly always bad - and it's what OOP was designed to prevent.
However, in the past, due to expediency/lazy developers some of these global $c and global $u calls have snuck in there. It's not a preferred way to do it - I definitely don't want to see wordpress-like code where functions become littered with globals. It's ugly, I agree.