Directory structure - files in /concrete vs /concrete/core
Permalink
Hey guys, I have a quick question. I'm looking through the directory structure of Concrete and was wondering why there are classes in the concrete folder that are empty but extend classes in the concrete/core directory. For instance the page_list model. There is a file concrete/models/page_list.php but the PageList class is just:
The Concrete5_Model_PageList class that it extends is in the file concrete/core/models/page_list.php.
Another example is the the BlockController class that you inherit from when you want to create a controller for a custom block. The BlockController class is in /concrete/libraries/block_controller.php and is just:
The Concrete5_Library_BlockController class is then located in the /concrete/core/libraries/block_controller.php file.
So I'm just trying to understand what the point of these intermediary classes in the /concrete folder is. I was thinking it would make sense if I had a bunch of classes that subclassed (for instance) PageList, I could then add some code to the PageList class then all the children would inherit it. However, I'm guessing you would never want to modify the PageList class directly because it would break on an update. So if it's just empty and shouldn't be modified what is it used for?
Thanks in advance for any clarification anyone can provide!
class PageList extends Concrete5_Model_PageList {}
The Concrete5_Model_PageList class that it extends is in the file concrete/core/models/page_list.php.
Another example is the the BlockController class that you inherit from when you want to create a controller for a custom block. The BlockController class is in /concrete/libraries/block_controller.php and is just:
class BlockController extends Concrete5_Library_BlockController {}
The Concrete5_Library_BlockController class is then located in the /concrete/core/libraries/block_controller.php file.
So I'm just trying to understand what the point of these intermediary classes in the /concrete folder is. I was thinking it would make sense if I had a bunch of classes that subclassed (for instance) PageList, I could then add some code to the PageList class then all the children would inherit it. However, I'm guessing you would never want to modify the PageList class directly because it would break on an update. So if it's just empty and shouldn't be modified what is it used for?
Thanks in advance for any clarification anyone can provide!
I think you misunderstood my question. I understand inheritance and why it is used, but my question is why do we inherit from this class called BlockController which is completely empty and only inherits from Concrete5_Library_BlockController? Why not just inherit directly from Concrete5_Library_BlockController? I'm just trying to understand what the purpose of the intermediary class, BlockController, is between my custom subclass and the Concrete5_Library_BlockController class which contains the actual functionality.
Actually, I didn't read your question at all... I just copied and pasted my IRC response to your question because you left. :) But my answer still stands....
Yes, you should subclass Concrete5_Library_PageList directly (as PageList).
The core's PageList will always be an empty class, so you'll "never"* break anything on an update. Your PageList will continue to be in your [root]/models/ directory (so it won't be overwritten) and it'll sublcass Concrete5_Library_PageList (which will then be autoloaded). And then anything else which calls 'new PageList()' (or subclasses it) will have your changes. This includes both (a) your code, and (b) core / other people's code.
* There are two ways that you might still break things (on update or otherwise).
1. You, e.g., subclass Concrete5_Library_PageList and override get($someArg) and then do parent::get($someArg). In a future version of c5, Concrete5_Library_PageList's the signature (or even functionality) of get() changes, your code doesn't change, and things break.
2. You might have two "user classes" (such as from packages) which create their own PageList. One won't get loaded, and that functionality won't be available.
But, at the end of the day, these issues are relatively minor and unlikely. As for #1, the solution used to be to copy/paste the entirety of the class code, so it was a lot more likely that something would be changed.
Yes, you should subclass Concrete5_Library_PageList directly (as PageList).
The core's PageList will always be an empty class, so you'll "never"* break anything on an update. Your PageList will continue to be in your [root]/models/ directory (so it won't be overwritten) and it'll sublcass Concrete5_Library_PageList (which will then be autoloaded). And then anything else which calls 'new PageList()' (or subclasses it) will have your changes. This includes both (a) your code, and (b) core / other people's code.
* There are two ways that you might still break things (on update or otherwise).
1. You, e.g., subclass Concrete5_Library_PageList and override get($someArg) and then do parent::get($someArg). In a future version of c5, Concrete5_Library_PageList's the signature (or even functionality) of get() changes, your code doesn't change, and things break.
2. You might have two "user classes" (such as from packages) which create their own PageList. One won't get loaded, and that functionality won't be available.
But, at the end of the day, these issues are relatively minor and unlikely. As for #1, the solution used to be to copy/paste the entirety of the class code, so it was a lot more likely that something would be changed.
Ahhh! Okay, now I think I get it. So I could create my own PageList class in /models which would then override the PageList class in /concrete/models and then any subclass I create of PageList would inherit from the PageList class I created in my /models directory. Is this correct? So the only purpose of the empty PageList class is to be overridden? If I'm understanding that correctly, that makes a lot of sense.
Yeah. That's a really good way to look at it -- "the only purpose is to be overridden". Well, that, and to be the "main" class if nothing overrides it.
I doubt that you'd both override PageList and then create a subclass -- though you might. I think the more common use case is changing the models that the core calls.
For example, elsewhere in the core, you'll find a lot of `extends PageList` and `new PageList()`. There was really no way to modify those easily. But now you can "put your own code in there".
I doubt that you'd both override PageList and then create a subclass -- though you might. I think the more common use case is changing the models that the core calls.
For example, elsewhere in the core, you'll find a lot of `extends PageList` and `new PageList()`. There was really no way to modify those easily. But now you can "put your own code in there".
Yeah, that makes perfect sense. Thank you for clearing that up for me!
All of those tasks you mentioned makes your website fast. Did I get the correct answer? xD
previously if you override BlockController with, e.g., SiteBlockController, then your could could do 'new SiteBlockController();' and all would be fine
but all the other code in c5 continues to do 'new BlockController();'