Modelling one-off pages with DD4T

Question

My web application has a number of one-off pages, by which I mean a page whose contents does not follow a standard layout, and the content does not fit a standard schema. These are typically simple single page forms and the like.

I decided to use a generic schema to model the contents, where key-value pairs can be used to define any number of bits of text, links and so on. This prevents the need to create a new schema for each one-off page, avoiding schema bloat (the content should be managed by editors).

The real problem comes with defining a view/layout for the content on the page. I also do not want to create a new page and or component template, so I am using generic PT/CTs, which map to views in DD4T, however I need a totally separate view for each page/CP.

Whats the best way to manage this in Tridion/DD4T?

Answer 1

By default the view for DD4T is determined by either the name of the Template or it can be specified on the Component or Page Template Metadata, here you can also set a different controller.

If you specify a different controller on your Template and then in that controller override GetView() to read the view from the Component Metadata instead, you have the option to set a separate view per Component.

See TridionControllerBase.cs in Google Code, for the default handling of the view in lines 42 (Page) and 64 (ComponentPresentation).

Answer 2

If you modify your Content-level controller to not only check inside of component template metadata but also inside of component metadata (or even in component data), you'll be able to specify your view inside of your component.

The same option exists for page-level views; you could (given a change to the page-level controller) use page metadata to define a view.

Answer 3

I've seen two approaches to avoid increasing the number of templates in this scenario:

To get handle variations for such one-offs, consider:

1. Design set in Components. Design-related fields in components (as suggested by others), specifically a field to set the render-side view
2. Design Separated. "Component Presentation" Components can include the view field instead. This may increase author work but can remove the view setting from the actual content components. Other challenges with this approach include re-use, where to store these, templating, and drag-and-drop in Experience Manager.

If using pages, we also have Target Groups (PnP/Wai), which solves the re-use problem, but I'm not sure it'd be a good fit for a DD4T setup. :-)

Both approaches give you one (maybe two) schemas and one template.

If doing #1 with Experience Manager, also consider Content Types or some type of equivalent in the CME (copy & paste, GUI extension, Event System, or whatever).

The author's first choice could then be setting the view by selecting a Content Type (based on a prototype component). I have one content type in this screenshot, but you could create one prototype component with the view set in each.

Answer 4

So you don't want to create a new CT / PT for each one-off page, but you do want it to have a unique layout?

One approach I can think of: (untested):

1. Add a dropdown to your generic schema where the editor can select a pre-defined layout.
2. Build your own 'RenderComponentPresentationsByViewSelectedByEditor'
3. Deploy the pre-build/pre-defined views to your web-app.

Of course, a new layout (a new one-off page) requires you to create a new View. You could consider publishing this razor-view with Tridion.

There's also the possibility to render the complete HTML during publishing, using the 'normal' templating stack. DD4T just displays the output (HTML) from your templates. but it might not be so straightforward. (linking, dynamic functionality, etc).

Answer 5

The way we approach this is to use a General Schema (Heading, Sub Heading, Summary, Body, Links) and a number of different CTs to render out the various parts of the page.

A Generic schema with key/value fields sounds a bit messy to me. I'd prefer the single schema > multiple CTs approach over a single Schema > single CT approach.

At least if the CTs do end up appearing on another page they're reusable.