I think the clipboard fits what you want more than stacks. The clipboard is really built for holding just one block, while stacks are meant to hold multiple blocks.

I thought that might be the case. The trouble is that the Clipboard, while great for ad hoc copying and pasting, isn't ideal for a more structured publication workflow.

Here's an idea for a different approach. Is it possible to 'scrape' the published version of a given block type from everywhere on a site? That way I could build an interface which lists all published instances of the block, from which the user could select the ones they want to display. Then I could store the references for the selected blocks and display them.

My understanding is that you can't do this in the current version of C5, but supposedly/hopefully this will be added to a future release of the system. Might be a bug report about it, in which case you'll want to "upvote" it to let the core team know it's important to several people (or you might want to create your own bug report about it if you don't see it already).

Hi Jordan

What do you think of my second suggested approach? Sort of like a page list, but instead of collections it pulls in blocks of a certain type from all round the site?

I've seen you talk about the single entry philosophy on a few posts, and that's precisely what I'm trying to achieve here! Something in me goes 'euch' at the prospect of having to explain to a client that they'll have to enter exactly the same information in two places.

In general, I try to designate a certain page as the "source" of data about a "thing" (member organisations in this case), either in the page content itself (which I can then retrieve via page list custom template, Page List Teasers addon, or my own custom code that pulls out certain block types), or in custom attributes (which are much easier to retrieve via code, but less of a pleasant data entry experience for end-users).

Can't really speak to your exact suggestion, because it really depends on the details of what you're trying to build, and also how savvy your end-users are, and how much content you're talking about, and if it's worth your client's money to pay more to develop an elegant solution (versus just having to do more data entry themselves).

Hmm. Basically I had planned to create a block type (using Designer Content :D) which shows an organisation's info (e.g. logo, name, URL). Several of these will appear on an 'Organisations' page. I then wanted to be able to dynamically choose some of those blocks to appear in other (Project) pages where a particular organisation is affiliated with that particular project.

My problem is in finding a way to reference a specific block, that's both reliable (from a versioning perspective - $bID won't work, I don't think) and human-readable (i'd like the client to be able to see a list of those blocks (e.g. all blocks with the handle 'organisation_details'), check the one that's relevant to the current page, and hey presto its displayed there.

There are other issues here, though. For example, what happens if the original block is deleted?

This makes me think that a custom attribute might be more appropriate, but I'll need to do some digging on how to store an attribute that has multiple variables, and multiple instances (i.e. [image/name/url][image/name/url][image/name/url]...)

What you're suggesting might work, but I would be very cautious about that approach -- it sounds to me like you're trying to build your own CMS on top of the existing CMS... in which case Concrete5 might not be the right tool for this job in the first place.

For me, if I can't make something work in the "one page per organisation, use custom attributes and Page List to display elsewhere" architecture, then I will build a dashboard interface for it (and sometimes a single_page on the front-end for certain displays). Anything else and I reconsider the tool because Concrete5 is not meant to solve every problem in every situation.

Yes I think you're right -- it seems to be re-inventing the wheel a bit.

To stay with the concrete5 paradigm you describe in the second paragraph of your post, would it make sense to create pages which are effectively 'holders' for those custom attributes, which are then displayed using the Page List block? i.e. the pages exist only to provide somewhere to save the data (as attributes), but otherwise they display nothing and don't appear in the site's (front-end) structure or navigation?

It sounds like that could work. The next step would be to create a way to allow clients to select certain of those pages to display on another page. For that, the custom attribute method you described in that other topic of mine could work, I think (i.e. it would filter out all pages of type 'organisation' into a select widget, then the client could choose as many or as few of them as they required to display.

I think I'm getting somewhere!

The biggest thing to remember with blocks(and a lot of c5) is that it is heavily leveraged in versions. This goes against traditional crud/object application patterns you probably have in your head.

What helps me is to think of concrete5 as a collection of versions not a collection of pages. When you start working with the code you feel like you're working with Page objects, but mostly you are working with the CollectionVersion object behind the Page object.

Block objects are just a unique object attached to one collection version.

To span versions you need to create persistent models. Models that are agnostic to what block is showing them.

A ok example of this is the User model in C5. There are many blocks that can work with users, but they are not the data. The block data that displays User stuff is just about _how_ to show the User stuff. Not the User stuff. The Users table/model is the user stuff. If you go 23 versions page on the profile single page you still get the latest User object.

I should add that I have almost completely dumped the Page object for anything but pages. It's just too leaky and big. I now associate my models with a page instead of making my page a model. I really like the idea of Pages as data but the Page object(really the attributes) just have too many issues.

Interesting.. so do you create new models to handle specific types of data?

Pretty much. Like if a had a model "Checklist" and a has many child model "CheckListItem" I would just treat them like normal models with their own tables and use an ORM to wire them together(adodb active record, idiorm paris or whatever).

Then on whatever page I want to be associated with them I create a page attribute called like "Checklist". I make a custom attribute that is basically a select of all the "Checklist"(s) I have and choose one for the page.

Then you can either write blocks that check for that page attribute or can be set to a particular Checklist model. Or just create page types(and their associated controller) to work with the Checklist model in a more traditional MVC way. I think of the Block object(not the BlockController obj) as a model of Block "settings" not any data type storage stuff.

The Page object is just a nightmare when you start getting several hundred and up and you don't have a big strong dedicated server running your site.

So you can't really depend on the Page object for any CRUD stuff that starts to have hundred or especially thousands of records. It works great for like a client with 10 locations or something. But not anything big.

That approach is probably a bit too advanced for me, but luckily I'll be dealing with only 20-30 pages per request, so performance shouldn't suffer.