8

in the webform era, we implemented (mostly) the following structure:

  • one .NET application (and a corresponding app pool) for all local websites
  • in the root of the app, we had a global web.config (managed outside Tridion: connection strings, endpoints,...)
  • each 'local' website was a sub-folder (e.g. "/fr_fr" for the french/France website) containing a local web.config holding a set of AppSettings. These AppSettings were mainly fields published from the publication's metadata (e.g. Currency info, culture ID, country code,...).
  • our .NET application used a Configuration Facade to easily use the local app settings.

We will now start the implementation of DD4T for one of our clients, and I was wondering what the best approach would be for the 'local web.config' files in DD4T. Any suggestions/best practices to follow?

Thanks

Improve this question

3 Answers 3

Reset to default
12

For MVC the setup can be almost identical. An approach I've seen looks like this:

  • Root
    • EN Website
      • Local web.config (could be partially published from Tridion)
      • Virtual dir to 'Views' in root
      • Virtual dir to 'Js' in root
      • Virtual dir to 'Css' in root
    • NL Website
      • Local web.config (could be partially published from Tridion)
      • Virtual dir to 'Views' in root
      • Virtual dir to 'Js' in root
      • Virtual dir to 'Css' in root
  • Views (in Root)
  • Js (in Root)
  • Css ( in Root)
  • global web.config

The web.config's in the local websites 'inherit' the values from the global web.config and can also specify there own. (Complementary). Also, read this blog article from Quirijn Slings on how to get the current publication based on the request url.

All of the above mentioned file/folders could be (partially) published from Tridion (even the Views if you really want it).

Improve this answer
3
  • ok, this is exactly what we would need. Especially as we will have locale websites with different styles (different set of views). Thanks!
    – Kristof Camps
    Commented Mar 18, 2013 at 18:33
  • Is there a single bin folder here then Albert - within your root? Are the country sites just simply folders not IIS applications?
    – Neil
    Commented Mar 19, 2013 at 13:30
  • Hmm, good question. but I think the country sites should be IIS applications. Shared bin could be the GAC.
    – Albert Romkes
    Commented Mar 19, 2013 at 16:24
8

A DD4T application is not that different from a "Classic" .NET application, it is still a .NET application after all. So your approach is still as valid now as it was before and seems like a pretty neat one.

However, as a small refinement, I find it cleaner to separate the Publication values, from the web.config, and deploy the web.config together with the application. This can also make local development easier.

This would just mean that you would publish a separate XML with all the configuration values, and consume them through a facade like you do now.

Improve this answer
7

The most important thing to remember is that you can still publish to the file system when using DD4T.

I would use exactly the same pattern but publish to a seperate XML file, with the same TBBs and add the following to your cd_storage_conf.xml for example:

    <Publication Id="9" defaultStorageId="defaultdb" cached="false">
        <Item typeMapping="Page" itemExtension="config" storageId="defaultFile" cached="false"/>
    </Publication>
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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