Dynamic Block: Thoughts and Options
Permalink
Howdy all,
I've built a custom block that is useful for theatres. In its add/edit windows a user can click a button that pops down a new show to populate. A user can keep "popping" down/appending on new shows in the same window, filling out each one until they are ready to save. This enables multiple shows to appear and be styled by one block, making things easier on the user.
There are Add/Edit/Archived tabs in the edit window, and shows are organized appropriately.
The app works great, but I'm wondering if there's a better way to code it. Currently all the dynamic "popping"/appending is almost purely done in Javascript, which creates all the necessary fields, with some ajaxed PHP files to create wysiwyg's and C5 image upload areas.
Would it make sense to just have a PHP file containing a complete skeleton of a show that is ajaxed in with each "popping"/appending? I would potentially need to have a large number of variable/array values from the controller/view that can reach that skeleton file (as any populated shows would need to be shown again in the edit window).
I'm aiming for best practices, efficient code, and a smooth UI (quick load times etc). If there are other options, or any thoughts on this, I'd be quite interested to hear about them!
Yours ever so truly,
-Landson
I've built a custom block that is useful for theatres. In its add/edit windows a user can click a button that pops down a new show to populate. A user can keep "popping" down/appending on new shows in the same window, filling out each one until they are ready to save. This enables multiple shows to appear and be styled by one block, making things easier on the user.
There are Add/Edit/Archived tabs in the edit window, and shows are organized appropriately.
The app works great, but I'm wondering if there's a better way to code it. Currently all the dynamic "popping"/appending is almost purely done in Javascript, which creates all the necessary fields, with some ajaxed PHP files to create wysiwyg's and C5 image upload areas.
Would it make sense to just have a PHP file containing a complete skeleton of a show that is ajaxed in with each "popping"/appending? I would potentially need to have a large number of variable/array values from the controller/view that can reach that skeleton file (as any populated shows would need to be shown again in the edit window).
I'm aiming for best practices, efficient code, and a smooth UI (quick load times etc). If there are other options, or any thoughts on this, I'd be quite interested to hear about them!
Yours ever so truly,
-Landson
Thanks John! I checked out the second link (I wasn't able to see the first one, due to pro-account?). I wasn't really aware of transactions, as I am fairly new to all forms of web coding/practices (been about a year now, using html/php/javascript/jQuery - so beautiful -/MySql/adodb).
My database structure definitely hasn't been normalized, but for simplicity's sake and ease of access I decided against it. My app handles show updates/removals/additions properly, and works with C5's version control system. So, although there are changes that could be made to my DB structure, it has served its purpose.
I have attached part of my DB access code. I assume there is something (perhaps a very large something) that can be done to improve upon it. I'm hoping there's a way to increase performance/efficiency in it. There are additional comments in the code/file explaining what is happening.
I've decided to try and create a similar app that uses an ajaxed PHP file to create/populate each show as it is "popped"/appended. This is instead of using nearly pure Javascript to create the fields/elements that make up each show. I'm hoping that the PHP focus will simplify my code, and also that this ajaxing/PHP technique doesn't slow down the UI.
Any further comments/ideas/constructive criticism is always appreciated!
-Landson
My database structure definitely hasn't been normalized, but for simplicity's sake and ease of access I decided against it. My app handles show updates/removals/additions properly, and works with C5's version control system. So, although there are changes that could be made to my DB structure, it has served its purpose.
I have attached part of my DB access code. I assume there is something (perhaps a very large something) that can be done to improve upon it. I'm hoping there's a way to increase performance/efficiency in it. There are additional comments in the code/file explaining what is happening.
I've decided to try and create a similar app that uses an ajaxed PHP file to create/populate each show as it is "popped"/appended. This is instead of using nearly pure Javascript to create the fields/elements that make up each show. I'm hoping that the PHP focus will simplify my code, and also that this ajaxing/PHP technique doesn't slow down the UI.
Any further comments/ideas/constructive criticism is always appreciated!
-Landson
Code is nice and clean. Pretty code makes life so much easier.
Are you updating the data that is associated with the block instance directly? Or is this a supplementary table?
Usually, you use the built in C5 mechanisms to handle the block instance data. You should only do db-> on the block instance data in exceptional circumstances.
As your comment notes, database stuff is usually best encapsulated in a model that you can then use from your block controller and from your ajax tools and anywhere else you need it.
If its a supplementary table, you will need to keep it in sync with the current bID (changes with versions) and there may be a creation issue when a block is first added because the bID does not exist until add is complete. There may also be a growth issue that needs to be handled if old page versions are cleaned out.
Are you updating the data that is associated with the block instance directly? Or is this a supplementary table?
Usually, you use the built in C5 mechanisms to handle the block instance data. You should only do db-> on the block instance data in exceptional circumstances.
As your comment notes, database stuff is usually best encapsulated in a model that you can then use from your block controller and from your ajax tools and anywhere else you need it.
If its a supplementary table, you will need to keep it in sync with the current bID (changes with versions) and there may be a creation issue when a block is first added because the bID does not exist until add is complete. There may also be a growth issue that needs to be handled if old page versions are cleaned out.
The table is indeed a supplementary one. I have used a foreign key relationship between it and the "original" C5 table to keep synced with the current bID. I also used cascading updating and deleting so that when C5 removes a row from "its" table, mine has all appropriate rows removed as well.
I did run into the creation issue when a block is first added, and handled it by running the parent::save( $data ) method prior to handling my table (though doing this only when appropriate using some conditionals). I believe with my cascading updating/deleting old page version removal was handled as well.
One thing that really got me initially with versioning was the controller's duplicate( $newBID ) method. Once I figured out that I needed to implement that method my app worked fully with the C5 version control system.
I'm thinking that the ajaxed PHP file that creates/populates each show as it is "popped"/appended should be coded as a tool. I was going to make a show_form.php file in my block's root, but when I tried to ajax it the defined('C5_EXECUTE') or die... failed. I'm not exactly sure why that is, as ajaxing a tools file in a similar fashion doesn't result in this issue.
Would that be an appropriate use of a tool file? It would be creating a new show's form fields every time a user clicks a button to add a show in the add/edit windows. It would perform some logics as well. If that is an incorrect usage, I'm not sure where else to place that code (other than show_form.php, but ya). If all else fails, it's back to pure javascript.
I did run into the creation issue when a block is first added, and handled it by running the parent::save( $data ) method prior to handling my table (though doing this only when appropriate using some conditionals). I believe with my cascading updating/deleting old page version removal was handled as well.
One thing that really got me initially with versioning was the controller's duplicate( $newBID ) method. Once I figured out that I needed to implement that method my app worked fully with the C5 version control system.
I'm thinking that the ajaxed PHP file that creates/populates each show as it is "popped"/appended should be coded as a tool. I was going to make a show_form.php file in my block's root, but when I tried to ajax it the defined('C5_EXECUTE') or die... failed. I'm not exactly sure why that is, as ajaxing a tools file in a similar fashion doesn't result in this issue.
Would that be an appropriate use of a tool file? It would be creating a new show's form fields every time a user clicks a button to add a show in the add/edit windows. It would perform some logics as well. If that is an incorrect usage, I'm not sure where else to place that code (other than show_form.php, but ya). If all else fails, it's back to pure javascript.
The important issue is usually how the database tables are structured beneath such an expanding dataset and whether there are any risks of inconsistency when there is an update of more than one row or table.
I recently asked about transactions:
http://www.concrete5.org/developers/pro-accounts/community-leaders-...
http://www.concrete5.org/community/forums/customizing_c5/mysql-inno...
After considering the resulting advice I decided a locking or fixing strategy would be easier and more versatile for my immediate problem.