8

I'm interested in this question: Can a single DD4T project be used against multiple publications?

How does this approach of using the same project for multiple sites translate to:

  • Functionality: Would the BluePrint and authoring setup be the same?
  • Architecture: Is this about sharing the same project (code), deployed to different servers? Or is there a consolidation in this approach (e.g. fewer storage/broker locations?

I might be missing context, but I'd assume there are no changes from the authoring side here?

|improve this question
10

As David said, there is no change to the authoring process for the editors and the Blueprint model is the same.

In terms of how the CD looks depends on your requirements and capabilities in terms of scaling and deployment set up.

You could have a single web application pointing to a single Broker database which all publications publish to in the model David describes above. However this could limit your options in terms of scaling; having different styles for different Publications; different markup or for special cases like Belgian and Swiss sites needing a landing page to choose language.

In some of the DD4T implementations I've heard about there is a separate web application per publication and each must be deployed separately. This makes it a little easier to scale as you could have Publication 1-3 on one server and 4-6 on another.

It would be possible to publish the styles and View code from Tridion (more similar to a "baked" Tridion model) which would allow you to change designs and markup per Publication.

|improve this answer
  • Thanks for mentioning that I was describing just one possible configuration. I updated my answer to make that clearer in case anyone thinks that is the only way :) – David Forster Oct 3 '13 at 21:51
10

The classic concept of BluePrinting does not change whether you use DD4T, CWA, or a classic Tridion DWT-based implementation. The only difference with DD4T is that instead of publishing rendered markup (i.e. baked HTML, Java, .NET or whatever server-side language), DD4T's templates publish XML (e.g. when you look at a component's source, just with a bit more info). You then render this XML on the delivery side rather than baking it in the CMS.

So BluePrinting and functional concepts don't change. All the standard best practices that you encourage on your Tridion blog still apply.

Architecturally, you can share your project code deployed to different servers just as you say. Or you can write your web app as a single application that deciphers between publication contexts. This is up to the implementors.

Finally, you touched upon having different Broker databases. This is a separate topic altogether. A single Broker DB is designed to handle multiple publications. However, it is possible to have a Broker DB per publication (this can make things a bit more complicated though). Regardless, whether DD4T is in the picture or not has no impact on this.

|improve this answer
  • 3
    I might be pedantic at times, but "preach?" I like to encourage good practices. ;-) – Alvin Reyes♦ Oct 3 '13 at 21:46
  • 3
    ^ "I like to encourage good practices"... with a baseball bat ;-) – David Forster Oct 3 '13 at 22:24
  • Ok ok, "encourage". Answer updated. – Nickoli Roussakov Oct 3 '13 at 23:33
9

In terms of BluePrint design and authoring, nothing needs to change...

The process for creating schemas, components and pages etc. remains the same, and the methodology of using multiple BluePrinted publications to, for example, localise and/or translate content remains valid and can be identical to that which you know and love.

Architecture wise - things can be a little different to the 'traditional' Tridion implementation...

Traditionally, one might publish different web site publications to different physical paths, or even different servers, and then serve them via multiple configured hosts.

With DD4T (or other techniques/frameworks that don't rely on physically published content), one could publish everything to a single broker database. There could also be just one web application that determines the correct publication ID to use (by the domain name or path used to access it, perhaps) and then uses that publication ID when querying the broker for the content to render.

Using this technique means that you can have an entire 'family' of publications served by a single host. For example, a customer I'm working with has 1 site that is localised and/or translated via BluePrinting for around 30 different markets. All of these publications are published to a single broker database and are served by a single DD4T based web application under different URLs (and paths in the case of multi-lingual sites).

NB: Note that I am specifically addressing just one possible configuration when using DD4T - As others have pointed out, there are many more! (The authoring processes still stay the same though)

|improve this answer
  • I'm following now. So in practice a "family" of sites might match the team(s) and build practices (process) for a given set of publications. – Alvin Reyes♦ Oct 3 '13 at 21:47
  • 1
    Yes, but more than that. For example, the customer I'm working with at the moment has 1 site that is localised and/or translated via BluePrinting for around 30 different markets. All these publications are published to a single broker database and are served by a single DD4T based web application under different URLs (and possibly paths in the case of multi-lingual sites). – David Forster Oct 3 '13 at 21:57
  • Oh duh, "family" as in parent/child relationships. How did I miss that?! – Alvin Reyes♦ Oct 3 '13 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.