Useful or Hack? - Use a query parameter to control block via block's custom name field
Permalink
Hey, has anyone thought of using the block custom name field for controlling the behavior of the block? ( didn't see anything on google so started this )
The reason I ask is b/c I find it annoying to have to re-create a view file for minor HTML changes. Especially during development when trying various options out as well as when using custom templates for blocks who's controller & edit files don't cover it for configuring the custom view.
So... I figured a way to use query parameters in the blocks 'name' field located in the custom template menu. Example, something like '?show_thumb=1' for the block name will turn the thumbnails on in the view template.
Here's how I set it up, for anyone interested--
This just checks the blocks name field and if there is one it runs a regular expression over it to extract the query parameters.
After that you can do whatever you want based on that information; for example, in a custom page list template I wanted to display the page list with thumbnail images on one page and without thumbnails on another. Rather than create another custom view template (or use CSS to set display:none b/c I needed more control of html structure ) I added in the above code to the top of the template and then later did a check to see whether or not to display the thumbnail image.
Once the code is in place to receive the query parameter then I just add my custom query parameter to the blocks name field.
To turn on the thumbnail images either of the following block names works:
'?show_thumb=1'
or 'My_Custom_Block_Name?show_thumb=1'
Issues:
I should note, to do this effectively the database table 'Blocks' field 'bName' needed to be changed from a 60 character limit to something higher ( I set mine to 2000 chars via PHPMyAdmin but can also be done by modifying the concrete/config/db.xml file and refreshing the core db tables via the settings/database xml page ) to accomodate longer query parameters.
Thinking that the best way to avoid problems during upgrades, as well as db schema refreshes, is to move the custom query parameters into a new view template once the block is setup. That way there's no worries of existing block names becoming truncated.
Anyone have any thoughts on how using the block name field this way could screw things up with its originally intended purpose? I'm really digging the ability to control a custom page list template from the front end and so far this is the only way I've figured how...
Maybe the dev team could open up the limit on that 'bName' field in the blocks table?
The reason I ask is b/c I find it annoying to have to re-create a view file for minor HTML changes. Especially during development when trying various options out as well as when using custom templates for blocks who's controller & edit files don't cover it for configuring the custom view.
So... I figured a way to use query parameters in the blocks 'name' field located in the custom template menu. Example, something like '?show_thumb=1' for the block name will turn the thumbnails on in the view template.
Here's how I set it up, for anyone interested--
<?php // add to top of view for block name query parameters if(isset($b->bName)){ # block name set # check for query parameters preg_match('/\?(.*)/', $b->bName, $matches); # parse string into array parse_str($matches[1], $bNameQuery); }
This just checks the blocks name field and if there is one it runs a regular expression over it to extract the query parameters.
After that you can do whatever you want based on that information; for example, in a custom page list template I wanted to display the page list with thumbnail images on one page and without thumbnails on another. Rather than create another custom view template (or use CSS to set display:none b/c I needed more control of html structure ) I added in the above code to the top of the template and then later did a check to see whether or not to display the thumbnail image.
Once the code is in place to receive the query parameter then I just add my custom query parameter to the blocks name field.
To turn on the thumbnail images either of the following block names works:
'?show_thumb=1'
or 'My_Custom_Block_Name?show_thumb=1'
Issues:
I should note, to do this effectively the database table 'Blocks' field 'bName' needed to be changed from a 60 character limit to something higher ( I set mine to 2000 chars via PHPMyAdmin but can also be done by modifying the concrete/config/db.xml file and refreshing the core db tables via the settings/database xml page ) to accomodate longer query parameters.
Thinking that the best way to avoid problems during upgrades, as well as db schema refreshes, is to move the custom query parameters into a new view template once the block is setup. That way there's no worries of existing block names becoming truncated.
Anyone have any thoughts on how using the block name field this way could screw things up with its originally intended purpose? I'm really digging the ability to control a custom page list template from the front end and so far this is the only way I've figured how...
Maybe the dev team could open up the limit on that 'bName' field in the blocks table?
Hey Jordan, thanks for feedback I always appreciate your work. To keep me from rambling I'll respond to each of your points:
"It sounds to me like you're trying to use something for a purpose it wasn't intended."
-- yes exactly :)
"I don't think it makes sense to use the block name for this, since that's intended to be something that the user sets, which is in turn utilized for mimicking the old "hardcoded scrapbook block" technique in theme templates, and other super weird things ( e.g.http://www.concrete5.org/community/forums/customizing_c5/setblockwr... )."
-- I like super weird things :) However, since it's being used for "strange things" already isn't this just another strange thing one could ( should ) do? Plus, you can still use the block name for the hardcoded scrapbook thing you would just need to append the query to the blocks name like My_Block?thumb_width=72
"Since you're already modifying the block's view template, why not just put some code in the view template itself that reads the $_GET value and has a big "if/then" statement in it (or includes other files if you want "sub-templates" for cleaner code)? In other words, why bother setting this block name value in the database and then reading it again instead of just bypassing that save/read altogether and just doing your thing right away?"
-- that's a great point, if I understand you correctly, you're saying I could use the regular query parameters ( in the browser address bar ) ? Would that be something I would do to control the width of my thumbnail image generated in my blocks custom view? If so how would I do that on a per block basis and would I be able to save that value ( like in a global stack ) ?
I'm using the blocks name field for configuring the block on a per block basis.
I can then have the same block using the same custom template on the same page with totally different configurations.
I'm posting here to see if I'm so crazy for doing this b/c I like it for quick prototyping.
I can change things like column spans or the size of the thumbnail image pretty much on the fly, without refreshing the browser ( which is nice for me b/c c5 sometimes takes 10-20 seconds to reload a page during editing )
Hopefully my intentions of mis-use are more clear, it seemed strange at first thought but after using the block name this way for a few days I dig it. It's nice to be able to adjust my blocks configuration from the front end... without a page reload or using ftp or flipping to textmate to make a tweak.
But if there is a better way to achieve this type of front end configuration of a custom block view I'd love to know how.
"It sounds to me like you're trying to use something for a purpose it wasn't intended."
-- yes exactly :)
"I don't think it makes sense to use the block name for this, since that's intended to be something that the user sets, which is in turn utilized for mimicking the old "hardcoded scrapbook block" technique in theme templates, and other super weird things ( e.g.http://www.concrete5.org/community/forums/customizing_c5/setblockwr... )."
-- I like super weird things :) However, since it's being used for "strange things" already isn't this just another strange thing one could ( should ) do? Plus, you can still use the block name for the hardcoded scrapbook thing you would just need to append the query to the blocks name like My_Block?thumb_width=72
"Since you're already modifying the block's view template, why not just put some code in the view template itself that reads the $_GET value and has a big "if/then" statement in it (or includes other files if you want "sub-templates" for cleaner code)? In other words, why bother setting this block name value in the database and then reading it again instead of just bypassing that save/read altogether and just doing your thing right away?"
-- that's a great point, if I understand you correctly, you're saying I could use the regular query parameters ( in the browser address bar ) ? Would that be something I would do to control the width of my thumbnail image generated in my blocks custom view? If so how would I do that on a per block basis and would I be able to save that value ( like in a global stack ) ?
I'm using the blocks name field for configuring the block on a per block basis.
I can then have the same block using the same custom template on the same page with totally different configurations.
I'm posting here to see if I'm so crazy for doing this b/c I like it for quick prototyping.
I can change things like column spans or the size of the thumbnail image pretty much on the fly, without refreshing the browser ( which is nice for me b/c c5 sometimes takes 10-20 seconds to reload a page during editing )
Hopefully my intentions of mis-use are more clear, it seemed strange at first thought but after using the block name this way for a few days I dig it. It's nice to be able to adjust my blocks configuration from the front end... without a page reload or using ftp or flipping to textmate to make a tweak.
But if there is a better way to achieve this type of front end configuration of a custom block view I'd love to know how.
Okay, thanks for the clarification. Touché on the point about "doing crazy stuff" :)
So are you saying that you're storing the most-recently-set value in the block name... so you hit a page with a certain querystring argument to change it, then that change also gets saved so next time you hit the page it is set to the most recent change (until the page is hit again with another querystring arg)? If so, I'd caution that this goes against the general nature of HTTP (because GET requests are supposed to be idempotent -- that is, multiple requests for the same URL should always be identical and not change the state of data -- seehttp://stackoverflow.com/questions/705782/why-shouldnt-data-be-modi... for more details).
But... if you still want to go through with it, might I suggest not saving it to the block name and instead just creating your own table in the database to store this info for each block? Or maybe use the system Config settings for this purpose? Since you're going through the trouble of saving and retrieving this info, *and* you've already established that you're okay changing the database (because you lengthened the block name field), why go through such contortions to even use that block name field? Just roll your own.
-Jordan
So are you saying that you're storing the most-recently-set value in the block name... so you hit a page with a certain querystring argument to change it, then that change also gets saved so next time you hit the page it is set to the most recent change (until the page is hit again with another querystring arg)? If so, I'd caution that this goes against the general nature of HTTP (because GET requests are supposed to be idempotent -- that is, multiple requests for the same URL should always be identical and not change the state of data -- seehttp://stackoverflow.com/questions/705782/why-shouldnt-data-be-modi... for more details).
But... if you still want to go through with it, might I suggest not saving it to the block name and instead just creating your own table in the database to store this info for each block? Or maybe use the system Config settings for this purpose? Since you're going through the trouble of saving and retrieving this info, *and* you've already established that you're okay changing the database (because you lengthened the block name field), why go through such contortions to even use that block name field? Just roll your own.
-Jordan
It sounds to me like you're trying to use something for a purpose it wasn't intended. I don't think it makes sense to use the block name for this, since that's intended to be something that the user sets, which is in turn utilized for mimicking the old "hardcoded scrapbook block" technique in theme templates, and other super weird things ( e.g.http://www.concrete5.org/community/forums/customizing_c5/setblockwr... ).
Since you're already modifying the block's view template, why not just put some code in the view template itself that reads the $_GET value and has a big "if/then" statement in it (or includes other files if you want "sub-templates" for cleaner code)? In other words, why bother setting this block name value in the database and then reading it again instead of just bypassing that save/read altogether and just doing your thing right away?