Category Lists - Best Solutions?
Permalink
I admit I am new to C5, bt I think I have gotten the handle of the basics, and am moving along steadily.
However, there is one type of situation I have not seen explained well yet - categories for lists of items.
I'll give the example I am working on - members for a non-profit at different "giving" levels, and so each level will be it's own block.
This will require two db tables of course. One will be the main block table, which will have a name associated with it for the giving level. The 2nd will have the names of the people. The issue is editing the 2nd db table from the main interface to keep everything consistent.
Of course, I could just build an ajax table interface, which would give the list in the table, and each row would have an edit/save and delete. The problem there is error catching.
I guess I am curious as to the best practices for dealing with this type of scenario. I am sure it comes up constantly, and I would like ot know how other people have dealt with it on the UI level.
However, there is one type of situation I have not seen explained well yet - categories for lists of items.
I'll give the example I am working on - members for a non-profit at different "giving" levels, and so each level will be it's own block.
This will require two db tables of course. One will be the main block table, which will have a name associated with it for the giving level. The 2nd will have the names of the people. The issue is editing the 2nd db table from the main interface to keep everything consistent.
Of course, I could just build an ajax table interface, which would give the list in the table, and each row would have an edit/save and delete. The problem there is error catching.
I guess I am curious as to the best practices for dealing with this type of scenario. I am sure it comes up constantly, and I would like ot know how other people have dealt with it on the UI level.
Well, I guess display is negotiable. In this case, I was thinking a list for data entry purposes.
I was thinking block level, not page level. For example:
SILVER MEMBERS
Doug, Fred, George....
Although the end display would likely be in an html table form.
One key for making it it's own table is allowing to sort (therefore, adding Adam to the end of the list will not force it to end of the list).
The main component for me here: is it possible to make an editor within an editor? For example, the block could display with the normal TEXT form for name up above, and then the listing of names from the table related to that block. The names need to be editable somehow though. This could be either inline (ajax most likely, as described above), or a secondary add/edit dialog in another modal window for example? Which is the better practice? Can you even achieve the secondary dialog with the current way controllers and views are parsed?
Hopefully that clears things up. I have put quite a lot of thought time in this, but I'd prefer it to be as seamless with the C5 interface as possible, and better yet, use the best practice so I am not rewriting things that are necesary (and keeping it properly DRY and KISS)
I was thinking block level, not page level. For example:
SILVER MEMBERS
Doug, Fred, George....
Although the end display would likely be in an html table form.
One key for making it it's own table is allowing to sort (therefore, adding Adam to the end of the list will not force it to end of the list).
The main component for me here: is it possible to make an editor within an editor? For example, the block could display with the normal TEXT form for name up above, and then the listing of names from the table related to that block. The names need to be editable somehow though. This could be either inline (ajax most likely, as described above), or a secondary add/edit dialog in another modal window for example? Which is the better practice? Can you even achieve the secondary dialog with the current way controllers and views are parsed?
Hopefully that clears things up. I have put quite a lot of thought time in this, but I'd prefer it to be as seamless with the C5 interface as possible, and better yet, use the best practice so I am not rewriting things that are necesary (and keeping it properly DRY and KISS)
So the data in each block is specific to that one block? (There's no one master list of people that is used by all blocks?)
If that's the case, then yeah you want to keep this to within the block editing interface.
You could keep it *really* simple by making a custom content block with Designer Content, and using the "default content" option on the WYSIWYG field to start it out with a sample table, then the user can use the TinyMCE toolbar controls to insert new rows into the tabe -- just like the 2nd usage example as outlined here:http://www.concrete5.org/marketplace/addons/designer-content/docume... (scroll down to "USAGE EXAMPLES ", then see the "DEFAULT TABLE STYLE" [2nd example]).
You don't get automatic sorting that way, but you also don't have to put any work into it :)
If that's not going to work for you, please explain what it doesn't do so I understand your specific problem space better.
If that's the case, then yeah you want to keep this to within the block editing interface.
You could keep it *really* simple by making a custom content block with Designer Content, and using the "default content" option on the WYSIWYG field to start it out with a sample table, then the user can use the TinyMCE toolbar controls to insert new rows into the tabe -- just like the 2nd usage example as outlined here:http://www.concrete5.org/marketplace/addons/designer-content/docume... (scroll down to "USAGE EXAMPLES ", then see the "DEFAULT TABLE STYLE" [2nd example]).
You don't get automatic sorting that way, but you also don't have to put any work into it :)
If that's not going to work for you, please explain what it doesn't do so I understand your specific problem space better.
Well, in this case, the sorting is a big factor.
And the Block Developer should be required for first timers. It's fantastic, and helped me a lot when I was learning the basics. The code is dead simple, and simple modifications can fix a lot. Plus, it helps you figure out the best way to deal with the errors, etc.
However, this is about a whole CLASS of issues. Let's take it one step farther - now let's say we want a block for supporters. And they are all companies, and they want the company name and url. And perhaps a brief description. Still a REALLY basic item though.
Instead of adding 50 blocks, which are not sorted properly, wouldn't it be ten times better to just have a table with that information that is queried to create the body of the block? The view part is DEAD simple in this case, just a simple query in the controller. It's the EDITING of it that I am trying to decipher - Am I forced to do ajax, or can I use a method using the built in libraries to do the heavy lifting?
Hopefully that makes more sense. It is a whole rash of possibilites.
And the Block Developer should be required for first timers. It's fantastic, and helped me a lot when I was learning the basics. The code is dead simple, and simple modifications can fix a lot. Plus, it helps you figure out the best way to deal with the errors, etc.
However, this is about a whole CLASS of issues. Let's take it one step farther - now let's say we want a block for supporters. And they are all companies, and they want the company name and url. And perhaps a brief description. Still a REALLY basic item though.
Instead of adding 50 blocks, which are not sorted properly, wouldn't it be ten times better to just have a table with that information that is queried to create the body of the block? The view part is DEAD simple in this case, just a simple query in the controller. It's the EDITING of it that I am trying to decipher - Am I forced to do ajax, or can I use a method using the built in libraries to do the heavy lifting?
Hopefully that makes more sense. It is a whole rash of possibilites.
I think I understand what you're saying -- you mean that you want an edit interface like the Slideshow block has for images, but you want it for arbitrary data?
That is indeed tricky. I've definitely taken the slideshow block code and tweaked it for my own purposes but it was very time-consuming. And that only worked to add items via the file manager. To make a more generic solution would be great but it's rather complicated -- there is no easy solution I know of, just needs to be coded up.
That is indeed tricky. I've definitely taken the slideshow block code and tweaked it for my own purposes but it was very time-consuming. And that only worked to add items via the file manager. To make a more generic solution would be great but it's rather complicated -- there is no easy solution I know of, just needs to be coded up.
Although it sounds like you're a somewhat knowledgeable developer (just new to C5). I have some boilerplate code for CRUD interfaces in the dashboard available here:
https://github.com/jordanlev/c5_boilerplate_crud...
You could set this thing up to have the crud interface in the dashboard for editing, but have blocks on the page to display. Perhaps in the dashboard interface you could have a "category" field of some kind, then the block edit dialog would just be a dropdown list of categories.
(But this would only make sense if you truly had one centralized list... otherwise it would be weird because users would have to add records to the dashboard and then add block to the page each and every time).
https://github.com/jordanlev/c5_boilerplate_crud...
You could set this thing up to have the crud interface in the dashboard for editing, but have blocks on the page to display. Perhaps in the dashboard interface you could have a "category" field of some kind, then the block edit dialog would just be a dropdown list of categories.
(But this would only make sense if you truly had one centralized list... otherwise it would be weird because users would have to add records to the dashboard and then add block to the page each and every time).
I agree, it's a conundrum with current paradigm for the cms. However, I honestly believe people would love this functionality. And use it constantly.
I think that unless someone else pipes up with a great way to do it, I will be forced to use ajax to pull it off.
I'm going to think through it again once I am done with some other custom blocks I am making that are also forced to use ajax (using an api for a completely separate soap based system for a different type of software).
Maybe a secondary block within a block whose editing interface gets called from the primary block when you click edit? That might work... and possibly be easier to code. And be a really nice package for the marketplace.
I'll pseudo this up, and see if anyone has any comments on this:
Category Block:
<block form>
<table of all sub-items from the database with the block id attached>
Clicking an edit button on any of those parses to another block (or maybe not a block really, almost a psuedo block?) form, and opens up either the edit or add interface for that item. That gets saved as usual.
Then it would likely have to force a reload on the category block table to show the changes, but that should be workable.
Anyone out there have any comments on that concept? Is it even possible, or should I just go back to my ajax idea?
I think that unless someone else pipes up with a great way to do it, I will be forced to use ajax to pull it off.
I'm going to think through it again once I am done with some other custom blocks I am making that are also forced to use ajax (using an api for a completely separate soap based system for a different type of software).
Maybe a secondary block within a block whose editing interface gets called from the primary block when you click edit? That might work... and possibly be easier to code. And be a really nice package for the marketplace.
I'll pseudo this up, and see if anyone has any comments on this:
Category Block:
<block form>
<table of all sub-items from the database with the block id attached>
Clicking an edit button on any of those parses to another block (or maybe not a block really, almost a psuedo block?) form, and opens up either the edit or add interface for that item. That gets saved as usual.
Then it would likely have to force a reload on the category block table to show the changes, but that should be workable.
Anyone out there have any comments on that concept? Is it even possible, or should I just go back to my ajax idea?
On the editor within an editor, it is entirely possible to pop up a dialog from within a dialog and it is already done from multiple places in C5 and addons. (There are some simplified examples in the ajax lessons addon).
There are several jQuery widgets that come to mind for managing a category list. Several tree plugins. The jQuery.ui menu widget. The ui autocomplete widget. Nested select widgets. Nested combi-box widgets. The tree already used within C5 for the sitemap.
If the category list was stored in a single table (or maybe a pair of tables) as a flattened tree, then you could extend attributes so you could attach any and multiple attributes to any item in that table (and hence node in the category list). You could have one global tree managed across all blocks, or one tree per category list block. Or something in-between
So an edit input interface would be to climb the tree, add nodes, add attributes to nodes, and edit the attribute values for a node.
(You could also conceivably create a node attribute and the whole thing goes on ad-infinitum)
It wouldn't be a quick thing to put together, but at this stage it all seems clear enough and mostly mashing together existing parts of C5 and some jQuery widgets for the interface.
The difficult part I predict is to create a general purpose display builder for it. Bespoke displays for specific applications shouldn't be an issue because the end point is well defined, but a general purpose interface... Much more nefarious than a general purpose page lister.
I have a requirement that I was planning to code up with a special to purpose mvc. But I may have a think further, the requirement would map onto this architecture, but I don't know if (and how much) additional work it would take to layer the requirement on top of a general purpose category list.
But maybe I am thinking in circles. I mentioned the tree already used within C5 for the sitemap. So maybe it all comes back to the design pattern of using pages to represent each node in the category list, but just not showing the pages in the nav. Its how discussion forums works. Its how blogs work. Its how most calendar/event addons work.
Perhaps if the model for category lists was built on top of this, the block edit dialog could be an adapted sitemap. Empty pages can be particularly light weight data items, just an empty page with a description. But flexible to flesh out with more content as well as attributes.
There are several jQuery widgets that come to mind for managing a category list. Several tree plugins. The jQuery.ui menu widget. The ui autocomplete widget. Nested select widgets. Nested combi-box widgets. The tree already used within C5 for the sitemap.
If the category list was stored in a single table (or maybe a pair of tables) as a flattened tree, then you could extend attributes so you could attach any and multiple attributes to any item in that table (and hence node in the category list). You could have one global tree managed across all blocks, or one tree per category list block. Or something in-between
So an edit input interface would be to climb the tree, add nodes, add attributes to nodes, and edit the attribute values for a node.
(You could also conceivably create a node attribute and the whole thing goes on ad-infinitum)
It wouldn't be a quick thing to put together, but at this stage it all seems clear enough and mostly mashing together existing parts of C5 and some jQuery widgets for the interface.
The difficult part I predict is to create a general purpose display builder for it. Bespoke displays for specific applications shouldn't be an issue because the end point is well defined, but a general purpose interface... Much more nefarious than a general purpose page lister.
I have a requirement that I was planning to code up with a special to purpose mvc. But I may have a think further, the requirement would map onto this architecture, but I don't know if (and how much) additional work it would take to layer the requirement on top of a general purpose category list.
But maybe I am thinking in circles. I mentioned the tree already used within C5 for the sitemap. So maybe it all comes back to the design pattern of using pages to represent each node in the category list, but just not showing the pages in the nav. Its how discussion forums works. Its how blogs work. Its how most calendar/event addons work.
Perhaps if the model for category lists was built on top of this, the block edit dialog could be an adapted sitemap. Empty pages can be particularly light weight data items, just an empty page with a description. But flexible to flesh out with more content as well as attributes.
Hello Jordan,
First of all, congratulations on another great product - boilerplate_crud :-)
Nevertheless, there is one small bug inside
models/category.php, line:42
should be:
works well with this change, otherwise you can not edit/add new
category.
And there is a issue, for which I suppose that an expert like you will find a good solution:
1. There is need to make an interface for listing/editing by member users, not only administrators
2. Because member users don't have access to the dashboard when they are logged in and they are redirected to dashboard/boilerplate_crud single page - they are asked for administrator login.
3. How this can be overriden for the users to have access to boilerplate_crud pages?
Thank you in advance,
Zoran
First of all, congratulations on another great product - boilerplate_crud :-)
Nevertheless, there is one small bug inside
models/category.php, line:42
$count = $this->db->findById($sql, $vals);
should be:
$count = $this->db->query($sql, $vals);
works well with this change, otherwise you can not edit/add new
category.
And there is a issue, for which I suppose that an expert like you will find a good solution:
1. There is need to make an interface for listing/editing by member users, not only administrators
2. Because member users don't have access to the dashboard when they are logged in and they are redirected to dashboard/boilerplate_crud single page - they are asked for administrator login.
3. How this can be overriden for the users to have access to boilerplate_crud pages?
Thank you in advance,
Zoran
Thanks for mentioning this, Zoran. I actually fixed that bug a few months ago -- you might be working with an old version of the code.
As for your other issue -- I think this is something you'll need to code yourself for your specific application. The boilerplate CRUD code is not intended to solve all problems for all situations, but rather just a demonstration of how you could structure your code for these kinds of dashboard pages.
It sounds to me like a better solution for you would be to make another single_page that is outside of the dashboard so that your normal members can access it. Then you can put whatever access permissions you want on it via the sitemap.
Hope that helps,
Jordan
As for your other issue -- I think this is something you'll need to code yourself for your specific application. The boilerplate CRUD code is not intended to solve all problems for all situations, but rather just a demonstration of how you could structure your code for these kinds of dashboard pages.
It sounds to me like a better solution for you would be to make another single_page that is outside of the dashboard so that your normal members can access it. Then you can put whatever access permissions you want on it via the sitemap.
Hope that helps,
Jordan
Yes, I downloaded the newest version of your boilerplate_crud yesterday and you corrected the bug in it :-) I was using an old version.
It seems to me that you are right about my case, I have to make a regular not dashboard single page, because privileges could be better managed on it.
But I like the look of the dashboard windows very much and wanted to use this windows not regualar browser pages... maybe concrete5 authors will introduce more user privileges for the dashboard interface in the future - so we could manage access to some functions on the dashboard for users and different administrators.
But I suppose that I can still use your excellent CRUD libraries?
It seems to me that you are right about my case, I have to make a regular not dashboard single page, because privileges could be better managed on it.
But I like the look of the dashboard windows very much and wanted to use this windows not regualar browser pages... maybe concrete5 authors will introduce more user privileges for the dashboard interface in the future - so we could manage access to some functions on the dashboard for users and different administrators.
But I suppose that I can still use your excellent CRUD libraries?
The dashboard pages use the Twitter Bootstrap framework for their design. If you're familiar with HTML and CSS, it shouldn't be difficult to figure out how to integrate that into a theme you can use on your front-end pages:
http://twitter.github.com/bootstrap/...
(Also, check the marketplace -- I vaguely recall a free theme that uses Twitter Bootstrap for its design -- might save you some time there).
Best of luck,
Jordan
http://twitter.github.com/bootstrap/...
(Also, check the marketplace -- I vaguely recall a free theme that uses Twitter Bootstrap for its design -- might save you some time there).
Best of luck,
Jordan
Or something else entirely?