Recordset Data and Structured Content
Permalink 1 user found helpful
I want to hear from some experienced C5 site builders on how they normally approach the challenge of recordset data or structured content, such as a real estate listing. Or a testimonial with an image. Content which if we were in Drupal or WordPress would qualify as a new "content type".
From what I've found so far looking around at how to's and blog posts on the subject, and based on the marketplace I see 3 different approaches being suggested at times. Can anyone think of a different approach or want to weight in on the pros and cons of some of these options?
1) Using blocks as records. This is the approach with Designer Content and Designer Content Pro. With this approach the block itself is the record and holds a variety of fields. Editing in composer seems clumsy with this approach, with all the fields bundled together. Adding to pages is easy. Listing and filtering, searching, sorting, possible but not easy.
2) Using Page Attributes. Add custom page attributes to a page type, then create a template to display those page attributes. Good support for searching, filtering. Fairly easy to setup for developers, not easy to do without coding. Also a lot of steps in the C5 admin to add the attributes one by one, then add the attributes to pages, then add the attributes to composer. There is an addon Page Properties that can help with the display of the attributes.
3) Pages as Records, Blocks as Fields. With this approach the page type has default blocks added that represent fields. The page itself is the record. Page List is used to list the "record" page types. Good support for composer. Non-developers don't have an easy way to make their field (blocks) show in the page list because it takes custom templates to show additional blocks.
So my evaluation is there is a lot of interesting options, but all have various drawbacks. For the developer any of the options is fairly easy to produce the result. But what about making it possible to build this sort of recordset display without coding? I feel like Drupal and WP are ahead in this area and it would be important to change that because a significant amount of site content falls into this category. Nearly every site has something they want to do repeat, and have consistent display and similar fields for.
Thoughts, ideas?
From what I've found so far looking around at how to's and blog posts on the subject, and based on the marketplace I see 3 different approaches being suggested at times. Can anyone think of a different approach or want to weight in on the pros and cons of some of these options?
1) Using blocks as records. This is the approach with Designer Content and Designer Content Pro. With this approach the block itself is the record and holds a variety of fields. Editing in composer seems clumsy with this approach, with all the fields bundled together. Adding to pages is easy. Listing and filtering, searching, sorting, possible but not easy.
2) Using Page Attributes. Add custom page attributes to a page type, then create a template to display those page attributes. Good support for searching, filtering. Fairly easy to setup for developers, not easy to do without coding. Also a lot of steps in the C5 admin to add the attributes one by one, then add the attributes to pages, then add the attributes to composer. There is an addon Page Properties that can help with the display of the attributes.
3) Pages as Records, Blocks as Fields. With this approach the page type has default blocks added that represent fields. The page itself is the record. Page List is used to list the "record" page types. Good support for composer. Non-developers don't have an easy way to make their field (blocks) show in the page list because it takes custom templates to show additional blocks.
So my evaluation is there is a lot of interesting options, but all have various drawbacks. For the developer any of the options is fairly easy to produce the result. But what about making it possible to build this sort of recordset display without coding? I feel like Drupal and WP are ahead in this area and it would be important to change that because a significant amount of site content falls into this category. Nearly every site has something they want to do repeat, and have consistent display and similar fields for.
Thoughts, ideas?
The Best Suite is interesting, I'll check out Uber List later. I think there is another one... data something that is $75! I remember it's price but not the name.
I want to explore doing this without big addons that provide a whole new interface. I'm looking more for a process than an addon... I feel like if I could the process clearer, I could build a lightweight addon that would streamline that process. For instance with the page/blocks approach I added a template for page list to show all blocks from the page:
That worked for the data I was working with (testimonials) because I knew I wanted to show all the blocks in the page list. I could see in other situations maybe out of 7 blocks on the page you only want to show 4 of them in a list. Or another scenario, you want to load one specific page and display all it's blocks in another page.
Are there any addons currently that provide a block where you can load all the blocks from a page and display them?
I want to explore doing this without big addons that provide a whole new interface. I'm looking more for a process than an addon... I feel like if I could the process clearer, I could build a lightweight addon that would streamline that process. For instance with the page/blocks approach I added a template for page list to show all blocks from the page:
// display all page blocks in page list template $blocks = $page->getBlocks(); foreach($blocks as $block) { $block->display(); }
That worked for the data I was working with (testimonials) because I knew I wanted to show all the blocks in the page list. I could see in other situations maybe out of 7 blocks on the page you only want to show 4 of them in a list. Or another scenario, you want to load one specific page and display all it's blocks in another page.
Are there any addons currently that provide a block where you can load all the blocks from a page and display them?
http://www.concrete5.org/marketplace/addons/data-display1/
This what you were looking for?
This what you were looking for?
My apologies here. It seems that reading this thread on my phone yesterday, my finger splodged several links together and I accidentally marked the above as best answer. Without picking another answer, its not something I can undo. No recognition of that answer over any other was intended.
Again, my apologies to @goldhat and @enlil for fumble fingered phone browsing.
Again, my apologies to @goldhat and @enlil for fumble fingered phone browsing.
I was wondering... I actually did this the other day as well. Luckily an answer had already been chosen AND I thought something funny happened and went back to look and sure enough. I was able to fix it but in this case nothing can be done aside from selecting an appropriate best answer later.
I considered raising the issue with the core team in regards to it's placement. Not only can it happen accidentally, but the button is squished up right there with other ones you may be trying to press and if you mess up we have a best answer problem...
EDIT: It goes from no problem when logged out to squished mess logged in being a community leader, when viewing on small mobile devices.
I considered raising the issue with the core team in regards to it's placement. Not only can it happen accidentally, but the button is squished up right there with other ones you may be trying to press and if you mess up we have a best answer problem...
EDIT: It goes from no problem when logged out to squished mess logged in being a community leader, when viewing on small mobile devices.
the best way to go in my mind is to use pages as "content types" and page attributes as attributes/properties/fields etc.
when i started out with concrete many years ago i defined my own set of entities with a lot of custom tables and interfaces in the dashboard. of course this ended up being stupid once i got to understand the purpose of concrete5 and its capabilities.
what changed mainly was that i used to see page types as different design layouts. now i see page types as different data entities and use the built in support for "layouts" and other design stuff as much as possible.
with page types and attributes you get pretty much everything out of the box. the page list block can be used for 70% of all listings and if it ever was to be updated to have better sorting/filtering settings and added support for ajax, it'd cover 90+% of all scenarios i've dealt with.
of course there are shortcomings with attributes as well, especially the interface for the editor which isn't very intuitive and the fact that you can't add page type-specific attributes.
but yeah, after 30 some sites that i've been involved with, there's never been a time i've regret using this approach and as stuff like the composer, grouping of attributes etc have been introduced, it just feels like the natural way that will keep improving.
when i started out with concrete many years ago i defined my own set of entities with a lot of custom tables and interfaces in the dashboard. of course this ended up being stupid once i got to understand the purpose of concrete5 and its capabilities.
what changed mainly was that i used to see page types as different design layouts. now i see page types as different data entities and use the built in support for "layouts" and other design stuff as much as possible.
with page types and attributes you get pretty much everything out of the box. the page list block can be used for 70% of all listings and if it ever was to be updated to have better sorting/filtering settings and added support for ajax, it'd cover 90+% of all scenarios i've dealt with.
of course there are shortcomings with attributes as well, especially the interface for the editor which isn't very intuitive and the fact that you can't add page type-specific attributes.
but yeah, after 30 some sites that i've been involved with, there's never been a time i've regret using this approach and as stuff like the composer, grouping of attributes etc have been introduced, it just feels like the natural way that will keep improving.
Great insight CherryCake that helps my thought process a lot. I'm leaning in this direction, but what makes me conflicted about it is really the visual interface. The way attributes are stored, how they can be worked with in the code, in that sense they do fit as fields/properties of a record or content type. But that isn't really how it seems in the interface, the admin or in the edit mode.
Here are a few ideas on that maybe you can tell me if you can think of solutions to them:
- Attributes (or attribute set) needs to be assigned to a page type and only visible when editing that specific page type
- Need to be able to add attributes from the page type interface and then return to the page type menu after adding
- Need a block similar to Page Properties for displaying attributes. It needs to provide option to display multiple attributes, interface to check off all the attributes you want in this particular block... this saves you adding them one by one.
- Attributes need to be editable through the attribute display block. Meaning instead of having to go to Page Properties that is tucked away in the edit menu, instead you need to be able to click on the attribute in the page and have an interface to edit the value. Currently in Page Properties if you edit the block, you get the option of "which attribute" instead of "edit the value of the attribute".
Here are a few ideas on that maybe you can tell me if you can think of solutions to them:
- Attributes (or attribute set) needs to be assigned to a page type and only visible when editing that specific page type
- Need to be able to add attributes from the page type interface and then return to the page type menu after adding
- Need a block similar to Page Properties for displaying attributes. It needs to provide option to display multiple attributes, interface to check off all the attributes you want in this particular block... this saves you adding them one by one.
- Attributes need to be editable through the attribute display block. Meaning instead of having to go to Page Properties that is tucked away in the edit menu, instead you need to be able to click on the attribute in the page and have an interface to edit the value. Currently in Page Properties if you edit the block, you get the option of "which attribute" instead of "edit the value of the attribute".
some good wishes there:)
i guess the short answer for all those questions from me would be to develop something to assist with working with attributes.
i'm mainly a sharepoint developer so i'm very familiar with what you're looking for as sharepoint can do most of those things. i guess the problem is concrete5 is still mainly for creating websites and not to maintain a record sets/business data etc. if that really is the key then i'm sure there are a lot of other systems better suited for it.
nonetheless i'll share my thoughts on your points,
1. attributes per page type.
attributes can't be page type specific as we know. the only suggestion i have here is to utilize the composer and add all attributes for a page type to the composer and only work with those pages through that interface. you could even create a nice little modal dialog with the composer page that lets you quickly access that page's properties from the page.
2. not sure if you mean you want to easily/quicky be able to add attributes to page types. if that's the case then it would work if you started using the composer like above. the page types page links to the composer settings for that page type and once you're done editing what attributes should be available etc i think you get back to the page types page again.
3. this could work if you again rely on the composer. you'd still need to develop a block but it would be fairly staright forward. just list all attributes available for that page type in the composer in the edit/add view of the block, then display those checked off on the page.
4. again, the composer :) and again, the modal i mentioned for the first one. using the block from 3. you could have a link that opens up a modal dialog with the composer edit view for that page. no coding needed except for the dialog!
also, worth keeping in mind is that the 5.7 release will introduce a new interface for working with pages and properties and i'm pretty sure it won't be less intuitive than what it is now at least so that should be something to look forward to.
i guess the short answer for all those questions from me would be to develop something to assist with working with attributes.
i'm mainly a sharepoint developer so i'm very familiar with what you're looking for as sharepoint can do most of those things. i guess the problem is concrete5 is still mainly for creating websites and not to maintain a record sets/business data etc. if that really is the key then i'm sure there are a lot of other systems better suited for it.
nonetheless i'll share my thoughts on your points,
1. attributes per page type.
attributes can't be page type specific as we know. the only suggestion i have here is to utilize the composer and add all attributes for a page type to the composer and only work with those pages through that interface. you could even create a nice little modal dialog with the composer page that lets you quickly access that page's properties from the page.
2. not sure if you mean you want to easily/quicky be able to add attributes to page types. if that's the case then it would work if you started using the composer like above. the page types page links to the composer settings for that page type and once you're done editing what attributes should be available etc i think you get back to the page types page again.
3. this could work if you again rely on the composer. you'd still need to develop a block but it would be fairly staright forward. just list all attributes available for that page type in the composer in the edit/add view of the block, then display those checked off on the page.
4. again, the composer :) and again, the modal i mentioned for the first one. using the block from 3. you could have a link that opens up a modal dialog with the composer edit view for that page. no coding needed except for the dialog!
also, worth keeping in mind is that the 5.7 release will introduce a new interface for working with pages and properties and i'm pretty sure it won't be less intuitive than what it is now at least so that should be something to look forward to.
This is my favorite question :) I think it gets at the heart of what differentiates C5 from the other systems: C5 revolves around PAGES. Everything in the UI is based around the PAGE being the "atomic unit of data". If your situation can fit nicely into that mold, then that is absolutely the best way to go (and C5 is without a doubt the best system use).
But when the data cannot be easily sliced and diced into pages, then it gets murky
All of the options you list are decent solutions, and I think the right approach depends on the task at hand ("right tool for the right job" and all that).
As mentioned above, I always try first to see if it can work "the C5 way" (which in my mind is "one page represents one 'record' of data... use blocks on the page for content, or page attributes for data that is required in other places [e.g. page lists] but is not displayed on the page itself). The reason you want to do it this way if you can is because it will reduce the amount of work you need to do (because you can leverage the existing tools in the C5 core), it will give you more out-of-the-box functionality (sitemap navigation, site search / content indexing, page defaults, etc.), and it will be a consistent user interface for the person editing the data (because it's the same interface that they're already using for adding pages).
For situations that don't fit the "C5 way" of doing things, I usually just build my own custom CRUD interface in the dashboard, save data to my own db tables, and create custom blocktypes and single_pages for displaying the data on the front-end. If you're a programmer and have some experience in other MVC frameworks, you might find this boilerplate CRUD code I have useful as a starting point for these kinds of projects:https://github.com/jordanlev/c5_boilerplate_crud...
There are other people in the community who like the approach of creating their own data objects that build on top of C5's attribute infrastructure... I personally do not like this approach because I find that C5's attribute infrastructure is WAY overkill for the kinds of things I'm building. But the people who like this approach are very smart and know what they're doing, so it's certainly something to look into. Although if you like this approach, it's probably well worth your money to buy the "Best Suite" that someone else mentioned (I believe it encapsulates a lot of the "building off C5's attribute infrastructure" stuff into a nice dashboard interface so you don't need to get too deep into that code yourself). The "Uber List" addon that John mentions also looks quite powerful and useful (this is the first time I've heard about it, though, so I don't know exactly how it works).
BTW, for your option #3, you should check out the free "Page List Teasers" addon, which will grab content from the actual page. Without any coding or customizing of templates, you can have it show all blocks in the Main area, just the first block in the Main area, or a truncated excerpt of content from the first block in the Main area. And those settings can be easily tweaked in the template if you're not afraid to make minor modifications (e.g. pulling from an area other than 'Main', or ignoring certain blocktypes, or grabbing the first 2 or 3 blocks instead of just the first 1).
Finally, here are a some links to older discussions about this topic that I dug up:
http://www.concrete5.org/community/forums/customizing_c5/new-object...
http://www.concrete5.org/community/forums/customizing_c5/will-concr...
http://www.concrete5.org/community/forums/customizing_c5/beginneran...
http://www.concrete5.org/community/forums/customizing_c5/help-tryin...
http://www.concrete5.org/community/forums/customizing_c5/single-pag...
And here are a couple of StackOverflow questions I've answered that are similar as well:
http://stackoverflow.com/questions/5293068/few-questions-about-conc...
http://stackoverflow.com/questions/4085382/is-in-concrete5-analog-d...
-Jordan
But when the data cannot be easily sliced and diced into pages, then it gets murky
All of the options you list are decent solutions, and I think the right approach depends on the task at hand ("right tool for the right job" and all that).
As mentioned above, I always try first to see if it can work "the C5 way" (which in my mind is "one page represents one 'record' of data... use blocks on the page for content, or page attributes for data that is required in other places [e.g. page lists] but is not displayed on the page itself). The reason you want to do it this way if you can is because it will reduce the amount of work you need to do (because you can leverage the existing tools in the C5 core), it will give you more out-of-the-box functionality (sitemap navigation, site search / content indexing, page defaults, etc.), and it will be a consistent user interface for the person editing the data (because it's the same interface that they're already using for adding pages).
For situations that don't fit the "C5 way" of doing things, I usually just build my own custom CRUD interface in the dashboard, save data to my own db tables, and create custom blocktypes and single_pages for displaying the data on the front-end. If you're a programmer and have some experience in other MVC frameworks, you might find this boilerplate CRUD code I have useful as a starting point for these kinds of projects:https://github.com/jordanlev/c5_boilerplate_crud...
There are other people in the community who like the approach of creating their own data objects that build on top of C5's attribute infrastructure... I personally do not like this approach because I find that C5's attribute infrastructure is WAY overkill for the kinds of things I'm building. But the people who like this approach are very smart and know what they're doing, so it's certainly something to look into. Although if you like this approach, it's probably well worth your money to buy the "Best Suite" that someone else mentioned (I believe it encapsulates a lot of the "building off C5's attribute infrastructure" stuff into a nice dashboard interface so you don't need to get too deep into that code yourself). The "Uber List" addon that John mentions also looks quite powerful and useful (this is the first time I've heard about it, though, so I don't know exactly how it works).
BTW, for your option #3, you should check out the free "Page List Teasers" addon, which will grab content from the actual page. Without any coding or customizing of templates, you can have it show all blocks in the Main area, just the first block in the Main area, or a truncated excerpt of content from the first block in the Main area. And those settings can be easily tweaked in the template if you're not afraid to make minor modifications (e.g. pulling from an area other than 'Main', or ignoring certain blocktypes, or grabbing the first 2 or 3 blocks instead of just the first 1).
Finally, here are a some links to older discussions about this topic that I dug up:
http://www.concrete5.org/community/forums/customizing_c5/new-object...
http://www.concrete5.org/community/forums/customizing_c5/will-concr...
http://www.concrete5.org/community/forums/customizing_c5/beginneran...
http://www.concrete5.org/community/forums/customizing_c5/help-tryin...
http://www.concrete5.org/community/forums/customizing_c5/single-pag...
And here are a couple of StackOverflow questions I've answered that are similar as well:
http://stackoverflow.com/questions/5293068/few-questions-about-conc...
http://stackoverflow.com/questions/4085382/is-in-concrete5-analog-d...
-Jordan
Well that reply easily gets the best answer off its parking place.
I'm glad too, great answer from Jordan should help future researchers on this topic.
Good to have you weigh on this Jordan. I had already found your CRUD code earlier but I haven't looked at it yet. Was still looking to mainly leverage built-in parts of C5 first.
I will check out the Page List Teasers as well.
For my own site I went with making page attributes, and then putting them in the custom template with $c->getCollectionAttributeValue(). That is so easy to do if you know PHP, I'm just wondering about the people that are sort of DYI site builders who know their way around an interface but are not comfortable writing code or understanding custom templates. That is where Drupal's approach has the advantage in that it's content types with field also includes display options and then there is a module called views for more advanced display.
I suppose the question though before worrying too much about non-coding site builders is how often are people using C5 that can't code? In WP this is common. In Drupal... less common but still fairly common. And in Drupal what you might have is a site built by developers, handed off to a site owner or designers or content managers, who end up learning the interface enough to be able to add their own content types. Chances are they will still find it challenging and reach out to a developer for more help, but being able to do 95% of what the want through the admin helps and saves time and money.
What's your thoughts on more advanced packages for querying/listing? Are there are any now where you can filter based on different page attributes?
I will check out the Page List Teasers as well.
For my own site I went with making page attributes, and then putting them in the custom template with $c->getCollectionAttributeValue(). That is so easy to do if you know PHP, I'm just wondering about the people that are sort of DYI site builders who know their way around an interface but are not comfortable writing code or understanding custom templates. That is where Drupal's approach has the advantage in that it's content types with field also includes display options and then there is a module called views for more advanced display.
I suppose the question though before worrying too much about non-coding site builders is how often are people using C5 that can't code? In WP this is common. In Drupal... less common but still fairly common. And in Drupal what you might have is a site built by developers, handed off to a site owner or designers or content managers, who end up learning the interface enough to be able to add their own content types. Chances are they will still find it challenging and reach out to a developer for more help, but being able to do 95% of what the want through the admin helps and saves time and money.
What's your thoughts on more advanced packages for querying/listing? Are there are any now where you can filter based on different page attributes?
i've used the ajax page list which lets you filter, search etc for custom attributes. and it's ajax based too which is a bonus. it was a bit tricky to extend though but it's possible.
Have a look at HereNT's 'Best Suite' and my 'Uber List' and 'Magic Data'. Either separately or together they can do that using pages, page types and attributes.
Best Suite is all about creating, editing, managing and maintaining lists of page types and their associated attributes. Uber List and Magic Data provide massive flexibility in how page and attribute information is extracted and displayed.