Extend the controller (not override it)
Permalink 1 user found helpful
Hello all,
I have found somewhere in the forum an explanation concerning a function to add to the form controller to have the form check correctly for valid email addresses.
I copied the code into a copy of the controller that I moved to the blocks\form\ folder.
It works of course but that's 31ko moved there for only a few lines added and it means I will not benefit from future updates to the form block unless I move the new controller again.
So My question is how do I extend the controller instead of overriding the whole thing?
I have found another explanation here. I quote:
if you want to do that you have to use Loader::controller('block_type_name'); or maybe you pass in a blocktype object, I can't remember.
Then in your custom function you would want to grab a new instance of the block controller, set the properties you want using that, and then have the view call the function by doing $this->controller->functionName(); and it can act on its return value.
Alternatively, you can have your custom controller extend that other block controller(which is extending controller so its has all the controllery stuff) and just have that custom function in it, and call the parent:: functions if you need to.
End quote.
I just simply don't know how to do that concretely, I'm not that good with code.
Can someone please help?
Many thanks in advance
I have found somewhere in the forum an explanation concerning a function to add to the form controller to have the form check correctly for valid email addresses.
I copied the code into a copy of the controller that I moved to the blocks\form\ folder.
It works of course but that's 31ko moved there for only a few lines added and it means I will not benefit from future updates to the form block unless I move the new controller again.
So My question is how do I extend the controller instead of overriding the whole thing?
I have found another explanation here. I quote:
if you want to do that you have to use Loader::controller('block_type_name'); or maybe you pass in a blocktype object, I can't remember.
Then in your custom function you would want to grab a new instance of the block controller, set the properties you want using that, and then have the view call the function by doing $this->controller->functionName(); and it can act on its return value.
Alternatively, you can have your custom controller extend that other block controller(which is extending controller so its has all the controllery stuff) and just have that custom function in it, and call the parent:: functions if you need to.
End quote.
I just simply don't know how to do that concretely, I'm not that good with code.
Can someone please help?
Many thanks in advance
No sorry, I ended up overriding it.
The short answer is that you can't.
all you can do is
The problem here is that this controller won't get called because of the folder naming structure. So you can get all freaky with your override and do some silliness, but it isn't very practical.
So what I end up doing in these cases is just copy it to an entirely new block with a new name and start from there.
This is something that the Kohana php framework does very well with it's stub classes. There was talk of implementing this in concrete5 but it appears to be shelved.
class FormBlockController extends BlockController {
all you can do is
class RadicalFormBlockController extends FormBlockController {
The problem here is that this controller won't get called because of the folder naming structure. So you can get all freaky with your override and do some silliness, but it isn't very practical.
So what I end up doing in these cases is just copy it to an entirely new block with a new name and start from there.
This is something that the Kohana php framework does very well with it's stub classes. There was talk of implementing this in concrete5 but it appears to be shelved.
This might help:http://chadstrat.com/blog/programming/extending/...
I am trying to do something similar in 5.6.0.2, which by the look of things now has the "stub" classes mentioned earlier.
I am trying to create a variant of the page_list block.
The controller for the 5.6 page list block controller looks like this:
so I figured that if in my block (which I have placed in the blocks folder, that if my controller does this:
everything should work. But it doesn't. The block installs from the dashboard and appears in the list of blocks when adding to the page, but the overridden getPageList method is not called.
I know my filter is working, because if I drop a controller override into blocks/page_list, the getPageList method is applied and the results are as I'd expect, but that overrides everything which isn't what I want to do.
I am trying to create a variant of the page_list block.
The controller for the 5.6 page list block controller looks like this:
class PageListBlockController extends Concrete5_Controller_Block_PageList {}
so I figured that if in my block (which I have placed in the blocks folder, that if my controller does this:
class WsgcDiaryBlockController extends Concrete5_Controller_Block_PageList { protected $btTable = 'btWSGCDiary'; public function getBlockTypeDescription() { return t("WSGC Page Listing"); } public function getBlockTypeName() { return t("WSGC Pages"); } public function getPageList($query = null) { $pl = parent::getPageList($query); $pl->filterByEventStart(date('Y-m-d H:i:s'), '>'); return $pl; } }
everything should work. But it doesn't. The block installs from the dashboard and appears in the list of blocks when adding to the page, but the overridden getPageList method is not called.
I know my filter is working, because if I drop a controller override into blocks/page_list, the getPageList method is applied and the results are as I'd expect, but that overrides everything which isn't what I want to do.
Hi Jero,
The stub class thing has more to do with modifying an existing block in place. Meaning something like I want the Form Block to do something different and I need to modify the controller not the view(custom template route).
If you are creating a completely new block, but you would like to extend one of the core block controllers, you can actually just extend their implementation class not the super class.
Because of autoloading in 5.6 you should pretty much be all set and don't even have to do the Loader::model() stuff you used to have to do.
The "stub class" thing would actually be this
and placed in the file
/blocks/page_list/controller.php
This modifies the actual Page List Block. It isn't for extending, it's for actually modifying the Block for a particular site. Hope that makes sense.
Best Wishes,
Mike
The stub class thing has more to do with modifying an existing block in place. Meaning something like I want the Form Block to do something different and I need to modify the controller not the view(custom template route).
If you are creating a completely new block, but you would like to extend one of the core block controllers, you can actually just extend their implementation class not the super class.
WsgcDiaryBlockController extends PageListBlockController {
Because of autoloading in 5.6 you should pretty much be all set and don't even have to do the Loader::model() stuff you used to have to do.
The "stub class" thing would actually be this
PageListBlockController extends Concrete5_Controller_Block_PageList {
and placed in the file
/blocks/page_list/controller.php
This modifies the actual Page List Block. It isn't for extending, it's for actually modifying the Block for a particular site. Hope that makes sense.
Best Wishes,
Mike
Typically, after posting I found the answer. The add and edit methods in the controller are using
which needless to say does what it says on the tin. Substituting my block handle instead allows the extended block to work
BlockType::getByHandle('page_list');
which needless to say does what it says on the tin. Substituting my block handle instead allows the extended block to work
I am interested.
Thank you