Application Approach Help Please
Permalink
I would like to create a dashboard page which would allow the adding/editing of course descriptions. Some will be active and some will not. I would also like to create a block which displays publicly some information about the Active classes. I am planning on making this a package for ease of installation and management on my site. My questions are, can the block share the database information with the single page? Where does the DB file go? Just in the package or do I need another on in the block folder too? How is the best way to approach this? This will be my first package.
Thanks!
Andrew
Thanks!
Andrew
Try looking athttps://www.concrete5.org/community/forums/customizing_c5/detailed-s...
I have seen that before. That is not what I'm after. That deals with page level data. I don't want them to be pages, just entries in it's own table.
Hi Andrew,
Any block or page (or any anything) can access any table in the database. The trick here is that in addition to the database table for your class infomation, the block *also* needs its own table that is for information about the block itself (and its placement on certain pages, and perhaps its settings such as "does this block show all classes or only active classes" if that's something you want to do).
So what I would do is put one db.xml file at the top-level directory of your package. I *think* this will automatically get run when the package is installed. That db.xml file will define the table for the class information. If you call that table "my_class_info", then you can access its information using SQL statements from anywhere -- the single_page controller or the block controller, for example, with code like this:
As mentioned above, the block will also need its own table, and you put the definition of that table in a db.xml file in the block's top-level directory. The block table should start with "bt" (for example "btClassInfo"), and it *MUST* contain at least two fields: one must be called "bID" (an auto-increment primary key integer), and then any other field. There is a bug/feature in C5 that requires every block to have at least one field besides the bID field, so even if you don't actually need another field for this block, just make one up (I usually call it "dummy" and just make it an integer field). If you actually do want another field for the block (for example, you want people to be able to choose a certain category of classes to list, or to show/hide inactive classes), then that other field would actually be used for something so you don't need the "dummy" field.
Hope that helps!
-Jordan
Any block or page (or any anything) can access any table in the database. The trick here is that in addition to the database table for your class infomation, the block *also* needs its own table that is for information about the block itself (and its placement on certain pages, and perhaps its settings such as "does this block show all classes or only active classes" if that's something you want to do).
So what I would do is put one db.xml file at the top-level directory of your package. I *think* this will automatically get run when the package is installed. That db.xml file will define the table for the class information. If you call that table "my_class_info", then you can access its information using SQL statements from anywhere -- the single_page controller or the block controller, for example, with code like this:
$db = Loader::db(); $sql = "SELECT * FROM my_class_info WHERE active=1"; $classes = $db->query($sql); while ($class = $classes->fetchRow()) { echo $class['name']; //etc... }
As mentioned above, the block will also need its own table, and you put the definition of that table in a db.xml file in the block's top-level directory. The block table should start with "bt" (for example "btClassInfo"), and it *MUST* contain at least two fields: one must be called "bID" (an auto-increment primary key integer), and then any other field. There is a bug/feature in C5 that requires every block to have at least one field besides the bID field, so even if you don't actually need another field for this block, just make one up (I usually call it "dummy" and just make it an integer field). If you actually do want another field for the block (for example, you want people to be able to choose a certain category of classes to list, or to show/hide inactive classes), then that other field would actually be used for something so you don't need the "dummy" field.
Hope that helps!
-Jordan
Thanks for the post. This is exactly the clarification that I needed. Thanks again!
