About CQ5 - Scaffolding

Scaffolding is a functionality to create structure-wise similar content based on a - well - old-fashioned form-based input screen. Boring, you might say, and definitely nothing any editor used to drag-drop fun would like to use. Especially, since swapping back and forth to scaffolding mode from the sidekick doesn't work properly if the content structure changed by e.g. adding new components or removing / re-adding the text-image. Still, if there's some casual user who just once in a while has to type in some news entry or blog post, that scaffold might work - sort of. But the scaffold is not much to talk about. Let's reconsider this.

What is scaffolding actually?
Basically, it's form-based editing of existing or new pages. The form is defined as a static dialog within the CMS. You can have a look at the example and the dialog definition in your CQ5.5 instance (links require running it on localhost:4502).

This scenario can be used not only for quickly creating structured content (and works quite well for that use case), but I also used the functionality of the scaffold to provide advanced functionality:

• Assume you have configuration and administration pages, which do not require a paragraph system (i.e. only single values or 'trivial' multi-field values). You could create an admin page with a component on it, and the editor has to hit the edit button to actually change something - or you enable him to edit directly on the page using the scaffold.
• You can also generate pages that go beyond some regular content pages. For example I wrote a small scaffold for newsletters. The scaffolding page can be linked to directly, and someone can easily create a newsletter entry without understanding how CQ5 works at all. Standard content like the from address, header, footer, and so on can be easily provided by hidden fields.
• The scaffold clearly shows metadata which may be hidden from the regular editor, so the scaffold can be used perfectly for validation purposes within a publication workflow - e.g. highlighting the often forgotten page properties, which hold important SEO information.
• I've never done it but I think it could also be used for post-processing of form-based submits.
• So there are some use cases that make the scaffolding quite interesting. One other thing is that the scaffold is extendable:
• One limitation of the scaffold is that it's using a static dialog. If you create your news entry page with the scaffold, then add a new paragraph to that page and return to the scaffold - that content won't be editable as it is not covered by the static dialog. Once I replaced the static scaffold dialog with a script iterating over each and every component on the page, resolving the dialog associated with the resource type of the content and doing some post-processing to re-layout e.g. tabs into the appropriate containers within the scaffold. A true switch between WYSIWYG editing and the scaffold was possible. Also, think about combining dynamic scaffolds with the review process - suddenly it's so easy to see if all images have alternate tags. I didn't integrate the parsys functionality into the scaffold page, so it was not possible to add new paragraphs in scaffolding mode. You could do that as well for sure ... One issue with the dynamic scaffold is the initial creation of pages, as the first page is empty, and therefore creating a new page via scaffold is impossible. But you can provide an initial set of content within the template definition, so the static dialog is completely obsolete.
• Taking it even further - if you really do not use external/automatic translation services: I once put two scaffolds in a side-by-side view, the left showing the original and the right the target language. Easiest interface possible for translators, and again: all the metadata often escaping the eyes is clearly visible. You don't get diffing though, or you have to have the 'real' rendition on the left - which will break alignment. But there certainly are ways to circumvent this.