Hi EliotHarper, thanks for your very well posted question.
Yes, separation between content and presentation is at the core of the WCM concepts, and CQ5 aims to solve this requirement in a clean way.
Generally speaking content is stored in the repository in the general form of nodes and properties and information related to its presentation is loosely coupled (and can reside somwhere else). The fact that the standard content hierarchy fits into the actual pages hierarchy is just the simples option to ensure authors an incontext experience in a natiral way. But depending on your project, youcan override this approach.
Based on your specific project requiremenets, you may choose from a set of different approaches. I'm mentioning 3 of them in more detail here.
1. Create different renderers for the same resource, to be used depending on where the resource is consumed.
for example /content/products/myproduct.html would render differently than /content/products/myproduct.detail.html
2. Use references. The same resource can be reused (as a reference) in other places. Updates to the content are reflected everywhere, since others are only references to the same resource.
3. Multisite management features. A piece of content (also at a deeper level than a page) can be rolled out to an arbitrary nuymber of 'live copies' at one time. Live copies provide a separate copy of the same content but with a link to the original content, to better manage updates.
Please let me know if this helps. Regards.
As a point of reference, and something that often gets new users of CQ5 confused, is the concept of MVC. When you say "classic MVC" you're probably referring to a variant of MVC which was made popular by several web platforms like Sling, where there is a controller that takes in input, and then munges it and interacts with a model, and then spits out a data set that is to be rendered by a view.
It's a decent pattern to follow, but it's not the original version of MVC. The original version was based on smalltalk, had a ui based pattern, and relied on the view to interact with the model to keep itself up to date. The view then, in the original MVC pattern, was a reusable component that could be nested within other views to construct a highly complex interface.[ This is all referenced in "Design Patterns" by the Gang of Four ] Which is exactly what CQ allows you to do with it's components.
The reason I bring this up is that it is a different way at looking at the data and structuring for the website then you may be used to, and I've seen ugly things happen when developers who come in with the web/sling mvc concept and try to shoehorn that design paradigm on a platform that wasn't meant to support it
Now to address your specific concerns:
CQ can handle what you are looking to do in a straight forward manner. They way to look at it, is that you're products are the content, you'll either have a specific template or data structure that represents your content(product) and the components that you would be building would be views that reference you're content(product)
In that sense, when you update a product, all of your components would pull and display that updated view of the product model. So update your content in one place and the pdfs get updated, the web pages get updated and anywhere else that references that product would get updated, which is where the power of CQ really come to the fore, because those components that you use to reference the content can then be reused in multiple places.
I think you mean SPring, not SLing.
Why yes talk about spending too much time buried in CQ... it's actually corrupted my thinking
Paolomoz, thank you for taking the time to provide a detailed answer, this is very helpful. It's all starting to make sense now. Now I just need to bury my head in the docs for a couple of days!