Reading block settings for jQuery based Gallery
Permalink
Hello people.
I need a little guide, since I'm not sure about the route I should take on this, and I also need a clarification on some topics.
Keep in mind that I'm not primarily a PHP developer, but I have a lot of experience in other programming languages (C++, Ruby, Python, Java, etc), and frameworks such as Rails and Django.
I worked with WordPress plugins, but mostly with the procedural code, and I've just started learning Laravel, so I'm getting used to PHP MVC.
I'm trying to port the http://blueimp.github.io/Gallery/... , an excellent image gallery to C5.
I'm using bits and pieces of code from the image carousel block (the part for loading images, and writing titles/descriptions), and I've used an excellent MrKDilkington's tutorial on how to set up the forms with the option panels ->http://documentation.concrete5.org/tutorials/how-to-use-the-form-wi...
I have set up the dedicated panel for all the gallery options mentioned in their documentation ->https://github.com/blueimp/Gallery/blob/master/README.md#setup... so the user can choose the setup type (lightbox, carousel and whether the controls should be on or off).
But I don't see how should I pass these options to the Gallery view itself. Since the gallery is JavaScript(jQuery) based, I'm unsure if I have to write some sort of routes for AJAX requests or what?
I also have some confusion with a db.xml. In Rails and Django I was writing migrations by myself into a dedicated file, that I would later migrate using the builtin migrator.
Now I'm confused with C5.
I created a whole field structure in the db.xml.
But I don' know if I have to write a DB (ORM) code myself for saving the options field into a dedicated file/controller, or does a parent::save() function does all the migrations/creations/updates for me automatically?
Or is there any other way of migration integrated into C5?
(I think someone should make a clear tutorial on this)
Thank you in advance.
I need a little guide, since I'm not sure about the route I should take on this, and I also need a clarification on some topics.
Keep in mind that I'm not primarily a PHP developer, but I have a lot of experience in other programming languages (C++, Ruby, Python, Java, etc), and frameworks such as Rails and Django.
I worked with WordPress plugins, but mostly with the procedural code, and I've just started learning Laravel, so I'm getting used to PHP MVC.
I'm trying to port the http://blueimp.github.io/Gallery/... , an excellent image gallery to C5.
I'm using bits and pieces of code from the image carousel block (the part for loading images, and writing titles/descriptions), and I've used an excellent MrKDilkington's tutorial on how to set up the forms with the option panels ->http://documentation.concrete5.org/tutorials/how-to-use-the-form-wi...
I have set up the dedicated panel for all the gallery options mentioned in their documentation ->https://github.com/blueimp/Gallery/blob/master/README.md#setup... so the user can choose the setup type (lightbox, carousel and whether the controls should be on or off).
But I don't see how should I pass these options to the Gallery view itself. Since the gallery is JavaScript(jQuery) based, I'm unsure if I have to write some sort of routes for AJAX requests or what?
I also have some confusion with a db.xml. In Rails and Django I was writing migrations by myself into a dedicated file, that I would later migrate using the builtin migrator.
Now I'm confused with C5.
I created a whole field structure in the db.xml.
But I don' know if I have to write a DB (ORM) code myself for saving the options field into a dedicated file/controller, or does a parent::save() function does all the migrations/creations/updates for me automatically?
Or is there any other way of migration integrated into C5?
(I think someone should make a clear tutorial on this)
Thank you in advance.
Yes, that's exactly kind of information that I was looking for.
Thank you so much.
I'm also looking to contribute to community, so once I finish the plugin I want to give it away for free, and make it open source as well, so the others can benefit from it :)
And yes, I made it as a package, so it can be installed through the C5 install system.
Thank you so much.
I'm also looking to contribute to community, so once I finish the plugin I want to give it away for free, and make it open source as well, so the others can benefit from it :)
And yes, I made it as a package, so it can be installed through the C5 install system.
I use both of the variations @hutman has listed and the alternative below, pretty much equally depending on circumstance.
The other variation I (and others) use is to, in the view, attach parameters for the jQuery as data attributes to the container it will be populating. A separate .js file can then select and extract those data parameters to initialise the jQuery plugin without requiring direct settings from the php.
A common mistake made with first-time galley submissions to the marketplace is to not consider the case of multiple copies of the block on the same page, usually a consequence of using bID to create a element #id and ending up with duplicate #id attributes. If you search back through the forums, there have been several threads discussing solutions for #id.
The other variation I (and others) use is to, in the view, attach parameters for the jQuery as data attributes to the container it will be populating. A separate .js file can then select and extract those data parameters to initialise the jQuery plugin without requiring direct settings from the php.
A common mistake made with first-time galley submissions to the marketplace is to not consider the case of multiple copies of the block on the same page, usually a consequence of using bID to create a element #id and ending up with duplicate #id attributes. If you search back through the forums, there have been several threads discussing solutions for #id.
So if I have a div that looks like
you suggest that I separate logic into somefile.js , and access it by
or I understood it wrong?
Thanks in advance.
<div id="#bID" data-list-size="5">
you suggest that I separate logic into somefile.js , and access it by
var my_list = $("#bID"); var listsize = my_list.data("list-size");
or I understood it wrong?
Thanks in advance.
Yes, that is the trick. Similar to the way bootstrap or foundation widget script is completely decoupled from the document elements.
You don't have to do it that way. It all depends on circumstance and preference. The techniques @hutman described are equally valid.
You don't have to do it that way. It all depends on circumstance and preference. The techniques @hutman described are equally valid.
But don't use
to identify the block.
A block in a stack, global area, or copied/pasted on a page, will not have a unique bID.
var my_list = $("#bID");
to identify the block.
A block in a stack, global area, or copied/pasted on a page, will not have a unique bID.
Great.
Thank you guys so much for the tips.
I knew C5 community was good, but didn't know it was this good.
I will let you know once I finish the plugin :)
Best.
Thank you guys so much for the tips.
I knew C5 community was good, but didn't know it was this good.
I will let you know once I finish the plugin :)
Best.
Following on from Mr theFish's warning about $bID, I put this in controller.php:
Then in view.php:
public function getBlockUID($b = null) { // Gets a unique bID for block $b. // Doesn't work with $this->getBlockObject() because that function returns a generic block with no proxyBlock. if ($b==null) return null; $proxyBlock = $b->getProxyBlock(); return $proxyBlock? $proxyBlock->getBlockID() : $b->bID; }
Then in view.php:
$bUID = $controller->getBlockUID($b);
So the db.xml file gets read each time the package is installed or updated, the tables in the db.xml are then updated with the defined fields at that time. You do not need to write much db code yourself.
When the save function is called any fields that come through in the $_POST will be saved to the database table defined in your $btTable variable, so the field names in the $_POST should match the field names in the $btTable and everything will save properly.
As for setting up the options what you can do is in the view function of your block controller you can do an addFooterItem call to add the js file (saved in /packages/package_name/js) for the blueimp js, then you can build your initialization in the controller and use another addFooterItem call to add that to the page as well.
In the controller anything in your $btTable is accessible through $this->field_name in the view.php of your block anything in your $btTable is accessible through $field_name, so if you don't want to do the addFooterItem for the gallery initialization in the controller you can just add the script tag to the end of the view.php and access the variables there.