Architecture question about blocks and page_types
Permalink
Hello,
On my websites I have several blocks that are on every page of a certain pagetype and don't need any parameters.
Normally, you can't add (anmore?) a block that has only the bId as paramater. You get an error message that says, you need at least two paramters. Somewhere I read a workaround to add a second dummy paramter for this.
Or is it better to add a pagetype controller, add the functionality in this controller and then add the view logic in the pagetype view code? That would explain, why single parameter blocks aren't allowed, since the code is only pagetype dependand and not page dependand.
So my question is, what is the best practise to add such a block?
Greetings from Vienna,
Harald
On my websites I have several blocks that are on every page of a certain pagetype and don't need any parameters.
Normally, you can't add (anmore?) a block that has only the bId as paramater. You get an error message that says, you need at least two paramters. Somewhere I read a workaround to add a second dummy paramter for this.
Or is it better to add a pagetype controller, add the functionality in this controller and then add the view logic in the pagetype view code? That would explain, why single parameter blocks aren't allowed, since the code is only pagetype dependand and not page dependand.
So my question is, what is the best practise to add such a block?
Greetings from Vienna,
Harald
![JohntheFish](/files/avatars/51576.jpg)
If you look at the db.xml for the block, or at the respective block table in the database, you will probably see a small dummy field after the id/key field.
Sorry I don't quite understand your answer.
My question is, what is the best (official) practise:
- Add a dummy field in my blocks
or
- Don't use a block but add a page_type controller for the logic and put the display logic in the page_type php template
I think, the c5 developers have some reasons for not allowing blocks with only one attribute?
My question is, what is the best (official) practise:
- Add a dummy field in my blocks
or
- Don't use a block but add a page_type controller for the logic and put the display logic in the page_type php template
I think, the c5 developers have some reasons for not allowing blocks with only one attribute?
Personally I would go with the blocks with a dummy parameter. Usually much more flexible to use than a page type.
I also am not a great enthusiast for hard coded blocks because I can get more flexibility by putting a real block in a global area of a page type or in page type defaults.
But maybe flexibility is not amongst your requirements, so other criteria become more important.
I also am not a great enthusiast for hard coded blocks because I can get more flexibility by putting a real block in a global area of a page type or in page type defaults.
But maybe flexibility is not amongst your requirements, so other criteria become more important.
Thanks John for you answer!
I agree with your opinion, I just would like to understand, why they put this limit of 2 atrributes in the code.
I was afraid that I didn't understand something in c5, but it seems that this dummy attribute is the common way :-)
Cheers
Harald
I agree with your opinion, I just would like to understand, why they put this limit of 2 atrributes in the code.
I was afraid that I didn't understand something in c5, but it seems that this dummy attribute is the common way :-)
Cheers
Harald
Hello Harald,
Since 5.5 you don't need the db.xml (nor add.php/edit.php) if you don't need to save data. All you really need is view.php and controller.php (the block still gets a btID of course).
See attached image and Andrew's Best Answer:
http://www.concrete5.org/community/forums/customizing_c5/simple-blo...
John
Since 5.5 you don't need the db.xml (nor add.php/edit.php) if you don't need to save data. All you really need is view.php and controller.php (the block still gets a btID of course).
See attached image and Andrew's Best Answer:
http://www.concrete5.org/community/forums/customizing_c5/simple-blo...
John