Simple blocks, need db.xml still?
Permalink
Some of the blocks I'd like to create are almost just reusable snippets.
For example, I'd like the client to be able to edit their hours of operation without messing with my designer's styles.
For cases such as this, should I still create a db.xml file (if there's really going to only be 1 entry in that database table that's created?)
For example, I'd like the client to be able to edit their hours of operation without messing with my designer's styles.
<h2>Hours of operation</h2> <p class="hours">9 AM to 7PM</p>
For cases such as this, should I still create a db.xml file (if there's really going to only be 1 entry in that database table that's created?)
Yes, every block must have a db.xml file, and the db.xml file must define at least one table that has a "bID" primary key field and at least one other field of any kind. The reason you need some other field (even if it's not used for anything) is due to some buggy code in the core system -- somewhere there is a SQL string being constructed that makes an assumption that there's at least one non-id field, so if you don't have any then the SQL fails.
@mkly, I like the idea of the timestamp field instead of the dummy -- never thought of that. But on the other hand I like the dummy field because it's more self-documenting ("might be useful someday" is somewhat analogous to "premature optimization" in my mind -- don't build things you don't need).
BTW, note that using the <deftimestamp> tag probably doesn't do what you think it does -- it actually becomes a "last updated" timestamp that gets set both when the record is first created AND whenever it's updated. I find this very annoying, and if I ever need a "created" timestamp I have to write some SQL for it in my package controller install() method.
BTW, note that using the <deftimestamp> tag probably doesn't do what you think it does -- it actually becomes a "last updated" timestamp that gets set both when the record is first created AND whenever it's updated. I find this very annoying, and if I ever need a "created" timestamp I have to write some SQL for it in my package controller install() method.
I actually agree with you.
Someone got grumples with me in the PRB about doing that in a block. After a short back and forth I decided to be diplomatic and attempt to pass around a created field. I guess I'll change the above to updated and I prefer the "dummy" as well.
Someone got grumples with me in the PRB about doing that in a block. After a short back and forth I decided to be diplomatic and attempt to pass around a created field. I guess I'll change the above to updated and I prefer the "dummy" as well.
What specifically did someone have an issue with -- using the timestamp or using the dummy? Either way seems silly, it's a c5 bug you're having to work around.
All of these are good points.
As an aside, so then I do store everything in the DB? It's not a "dummy field" I still need to store something somewhere (it's basically just a snippet, but it needs to be editable).
As an aside, so then I do store everything in the DB? It's not a "dummy field" I still need to store something somewhere (it's basically just a snippet, but it needs to be editable).
Are you saying that there's only one value that will be shared across all blocks? If that's the case, what I'd do instead is create the block and store the snippet in the block's table (which means you don't need the dummy or timestamp field anymore because you have a real field to take up that slot). Then put the block in a global scrapbook (if using Concrete5.4.2.2 or lower) or in a global area "stack" (if using Concrete5.5. or higher).
If you don't want to do that, what you can do instead is create ANOTHER table in addition to the one with the bID field in it, and write custom SQL queries in your block controller to write to and read from that other table. That other table will just have one row and one field in it. Or if that seems wasteful, you could use a config setting:http://www.concrete5.org/documentation/developers/system/config-pre... .
Note that even if you take the second approach (2nd block table or config setting), you will STILL need that primary block table with the "bID" and dummy field, because C5 needs that to store the information about which block was placed on which page (regardless of the actual data contained in that block).
If you don't want to do that, what you can do instead is create ANOTHER table in addition to the one with the bID field in it, and write custom SQL queries in your block controller to write to and read from that other table. That other table will just have one row and one field in it. Or if that seems wasteful, you could use a config setting:http://www.concrete5.org/documentation/developers/system/config-pre... .
Note that even if you take the second approach (2nd block table or config setting), you will STILL need that primary block table with the "bID" and dummy field, because C5 needs that to store the information about which block was placed on which page (regardless of the actual data contained in that block).
With "dummy". I personally like "dummy" because it's pretty dumb to even have to do it, but the person felt it wasn't good to use "dummy".
I agree. If you like dummy and I like dummy I feel like I can bury the idea of "created" or "updated" and stick with dummy.
I agree. If you like dummy and I like dummy I feel like I can bury the idea of "created" or "updated" and stick with dummy.
BTW - in 5.5 blocks do not need db.xml any longer. They also don't need add
or edit templates if they're just going to be reusable bits of
functionality you want to place throughout your site. Check out the
dashboard blocks for examples of this.
or edit templates if they're just going to be reusable bits of
functionality you want to place throughout your site. Check out the
dashboard blocks for examples of this.
I so want to mark this as best answer. That face is probably the best answer for any question.
Oh! That's what I was looking for (it's a brand new site) Thanks!
On 22 December 2011 14:52, concrete5 Community
<discussions@concretecms.com>wrote:
On 22 December 2011 14:52, concrete5 Community
<discussions@concretecms.com>wrote:
BTW - in 5.5 blocks do NOT db.xml any longer. They also don't need add
or edit templates if they're just going to be reusable bits of
functionality you want to place throughout your site. Check out the
dashboard blocks for examples of this.
or edit templates if they're just going to be reusable bits of
functionality you want to place throughout your site. Check out the
dashboard blocks for examples of this.
The block also requires two fields to install for some reason. You can just use
but I feel like the updated field that timestamps itself is at least possibly useful in the future.
Also, for simple stuff like that @jordanlev's addon Designer Content can be pretty helpful
http://www.concrete5.org/marketplace/addons/designer-content/...