Organizing structured content: what's the best approach?
Permalink
We discussed this a bit in the IRC channel (efnet/#concrete5, come hang!) but I'm posting it in the forums to get feedback from others (plus there's more room to rant in here <g>).
I'm going to drop the F-bomb: "forum". How would you build this in C5? Same with (gulp) the much loathed blog? Or multiple galleries? Or product catalog? Or music albums?
With any kind of structured content, in large(ish) quantities, organized in a set, I'm a bit lost as to what C5 tools to use.
Think of a forum post: subject, message, and some meta attributes (author, created, etc.) organized into threads (categories, groups, whatever you want to call it, it's a set).
I see potential with Page Types and Page Lists but a "page" to me feels too large: I equate a page to a distinct URI (aliased or not). A Block feels about right for a forum post or a product or a gallery item but I don't see a Block List anywhere.
I know I could probably bang out a Single Page and/or application to handle this, but I see so many similarities between these hierarchical content sets it would be a shame not to create something more abstract to accommodate all of them, using core functionality.
I really don't want to reinvent the wheel -- and the C5 kids obviously have been doing this for a while -- so please, if I'm not seeing the forest for the trees, set me straight.
I'm going to drop the F-bomb: "forum". How would you build this in C5? Same with (gulp) the much loathed blog? Or multiple galleries? Or product catalog? Or music albums?
With any kind of structured content, in large(ish) quantities, organized in a set, I'm a bit lost as to what C5 tools to use.
Think of a forum post: subject, message, and some meta attributes (author, created, etc.) organized into threads (categories, groups, whatever you want to call it, it's a set).
I see potential with Page Types and Page Lists but a "page" to me feels too large: I equate a page to a distinct URI (aliased or not). A Block feels about right for a forum post or a product or a gallery item but I don't see a Block List anywhere.
I know I could probably bang out a Single Page and/or application to handle this, but I see so many similarities between these hierarchical content sets it would be a shame not to create something more abstract to accommodate all of them, using core functionality.
I really don't want to reinvent the wheel -- and the C5 kids obviously have been doing this for a while -- so please, if I'm not seeing the forest for the trees, set me straight.
...a block allows you to create content with great flexibility in data and the UI, but the data created is not really autonomous outside of a page. Page Types seem to only permit you to create custom containers for blocks.
We've done this both ways. In fact, we've got it both ways now. The guestbook block is a block. You can add multiple ones to a single page, each one contains all the data it needs. We did this because guestbooks have a pretty definable data type that isn't likely to change over time, (or benefit from the flexibility of doing so) and they typically aren't huge.
These forums are a page per post. You probably don't see it, but an admin can click on any post title and get to a cID that contains it and all the posts below it as children. This is nice. I can copy a post half way down a thread to a root level and turn it into a new discussion. The main content area of a post could even be named the same thing that your default page is, so hypothetically I could take a post, turn it's page type in to "documentation" and just move it across the site using the standard concrete5 move tools.. Done.
I also get the ability to do post level meta titles and descriptions for SEO.
I also have no problem extending the post architecture as ideas come. Say I want to put this page in edit mode and add a survey to the side. Click-click done. Say I want to build a block that searches all the forums for files? Well its the same as searching pages for files, so there's some nice ways to start and everything I write would be easily repurposed for something similar elsewhere in the site.
The forums have a two page types, discussion list, and post. The post page has a block on it that looks for all children and displays them threaded (or chronological in beta).
There are a few challenges around this. We have to have a custom page list template that looks for the root of a thread rather than just the post itself - or you'd lose the previous posts when deep linking into a recent post in a long thread. I think in fact right now our new search engine isn't doing that so you can get to a specific reply out of context through that. Something to fix. ;)
I think the little challenges like that are far out weighed by the flexibility you get by trying to use page's and page types as parts of your data objects. As I said in the IRC room, it's perfectly easy to make the UI simple using a single page or custom block - but the benefit of populating pages is you're creating data that can be reused and extended in ways that aren't predicted at the start of the project, and don't even always have to involve a programmer.. Deep down, that's what the promise of concrete5 is all about.
These forums are a page per post. You probably don't see it, but an admin can click on any post title and get to a cID that contains it and all the posts below it as children. This is nice. I can copy a post half way down a thread to a root level and turn it into a new discussion. The main content area of a post could even be named the same thing that your default page is, so hypothetically I could take a post, turn it's page type in to "documentation" and just move it across the site using the standard concrete5 move tools.. Done.
I also get the ability to do post level meta titles and descriptions for SEO.
I also have no problem extending the post architecture as ideas come. Say I want to put this page in edit mode and add a survey to the side. Click-click done. Say I want to build a block that searches all the forums for files? Well its the same as searching pages for files, so there's some nice ways to start and everything I write would be easily repurposed for something similar elsewhere in the site.
The forums have a two page types, discussion list, and post. The post page has a block on it that looks for all children and displays them threaded (or chronological in beta).
There are a few challenges around this. We have to have a custom page list template that looks for the root of a thread rather than just the post itself - or you'd lose the previous posts when deep linking into a recent post in a long thread. I think in fact right now our new search engine isn't doing that so you can get to a specific reply out of context through that. Something to fix. ;)
I think the little challenges like that are far out weighed by the flexibility you get by trying to use page's and page types as parts of your data objects. As I said in the IRC room, it's perfectly easy to make the UI simple using a single page or custom block - but the benefit of populating pages is you're creating data that can be reused and extended in ways that aren't predicted at the start of the project, and don't even always have to involve a programmer.. Deep down, that's what the promise of concrete5 is all about.
I can now understand your reasoning for going with pages. Implementation is another thing: anyway you can put up the forum code? It would help me (and others) immensely getting around what's possible with C5.
yeah i knew that was gonna be the next question.. we're getting close to releasing this to the beta and it should show up in the marketplace shortly after that.. i know i've been saying that all year - but hey.. life.
it will be dependent on 5.3.
it will be dependent on 5.3.
looking forward to it.
Except in this case, you also need to set up a page type that assesses the particular data you want to display.
Then you would need to add restrictions to the child page types.