More than one driver for a single Orchard part

This picture has nothing to do with the post. Haack won't like it, so be it.Drivers in Orchard are responsible for taking content parts and using them to generate shapes for the rendering engine to transform into HTML. A little known fact is that there can be more than one driver for any given part. You might be wondering what this can be used for: one shape per part seems like a reasonable assumption.

I’ll show one case where this ability to add a driver to the one that already exists came in really handy.

One of the sites I’m working on is making heavy use of taxonomies. The customer wanted to add management screens for the order of terms in any given taxonomy, that had some interesting specific features. We wanted a couple of links to that additional screen right inside the existing UI for a taxonomy field. I could have created a new part, but it would have never made sense unless a TermPart was already present. Orchard is so extensible in fact that extensions are extensible, so in a completely separate module from the original taxonomies, I created a new ContentPartDriver<TermPart>:

protected override DriverResult Editor(TermPart part, dynamic shapeHelper) {
    return ContentShape("Parts_Taxonomies_Term_OrderLink",
            () => shapeHelper.EditorTemplate(
                TemplateName: "Parts/Taxonomies.Term.OrderLink",
                Model: part,
                Prefix: Prefix));
}

Both drivers will run, and they will both emit their own shape. Each of those shapes can in turn be moved around using placement.info. This driver and the template to render the new shape is all I had to write. Here is the end result:The new links inside the term editor

This is a pretty nifty way to enrich existing admin UI for any content type, don’t you think?

No Comments