// you’re reading...


That Parent/Child relationship explained

In other words… we’re finally going to answer one of your many burning questions, the whys, the wherefores and the whatnots of Foundation projects. I know, I know… we’re so slow!

The most important part of any project is the careful planning of everything, not just the design of the final site. You need to be comfortable in the knowledge that what you build now will be easy to maintain, update and expand.  Sometimes it will be obvious at the start of your project that you’re going to need more than one version of the site, other times you’ll be assured that this will be the only one. Whatever they say… go for a parent/child project setup… it will save your sanity in so many ways! 

So what is this Parent/Child thing?

RedDot gives you the ability to share content folders between projects, cunningly called Content Class Sharing. This allows you to use the same content classes, media items, style sheets etc.) in a number of projects, which will mean it’s quick to create a new copy of that website they insisted was a one off. (Do you get the feeling that I’ve been bitten by this before?). It’s important to note that workflows and publication targets can not be shared out, it’s only Folders and, at times, content.

The idea behind the Parent/Child configuration is that you have your main project, the Parent, only holding your templates. Content should never go into the Parent, this should effectively be your development area if you don’t have the luxury of a separate Dev server. By having all your content classes in one location, you can dramatically reduce the length of time it takes to update some code as it only needs doing once, rather than in every project. If you’re clever you can also use the foundation project as a testbed for every possible combination of content classes; I’ll cover that later.

Setting up the Children

Once you have your Parent project all sorted, you can start on your Child projects. Our first new project we’re going to call the Template Child. This project will be set up with our workflows, default permissions and some basic structure; ideally the homepage and one or two general pages that every version of this site will need, such as Sitemap and Contact. The idea behind the Template is to have everything set up, so that creating a new project is simply a case of copy/reset share/set user access

This new project need to  be configured to inherit the folders from the Parent. How do we do that?

In the Parent project you will need to go to the Folders and Administer Content Class nodes and use the Edit Content Class Sharing option for each folder/content class. Tick the name of your Template project each time and we’re done. this is a little repetitive, but will save you time in the long run.

Back in the Template project we need to go to the Folders node and create all the folders we want to inherit. During the creation process it will ask where you want this content to come from. There should, if the sharing has been done, be a drop-down list with all the shared folders from your Parent. Choose the right one… rinse and repeat until you have all the shared folders. You will notice that as you create each folder and assign one of the shares, the share vanishes from the option list next time around. This is to prevent you inheriting two lots of the same content.

Why have we done all this?

By creating the Template project, creating a new site simply becomes a case of copying the Template project and adding it to the list of shared projects in the Parent (remember where we set up the folder sharing a minute ago?). 

Apart from the Template and live Child projects, we also had a Sandbox site, which was basically used for training purposes. The editors had access to this site so they could try out new Content Classes without worrying about breaking the live site.

Occasionally you’ll find that someone wants a new Content Class for their project. Just because you are inheriting from the Parent doesn’t mean you can’t create additional Content Classes in a Child project along the way. While it’s not the best solution, it’s doable. I would still suggest trying to create all new Content Classes in the Parent regardless of where they will be used, just in case someone comes along and asks for it elsewhere. 

Using the Parent project for testing

As you’re not going to be using your Parent project to store live content, you can make the project work for you in other ways.

It’s tempting to just have a few random pages and dump whatever content class you’re testing onto the front page for a quick look. We fell into this bad habit and it wasn’t very efficient for testing. Lesson learnt ;)

The design agency that we worked with had come up with all sorts of content blocks and had decided where each item could or couldn’t be used. If someone put the news list into the wrong column everything went a little weird, so it was important to test content classes wherever they should be used. Try to take your time and assemble example pages in your Parent project that use your content classes in the containers they are allowed in. It’s even helpful to have them in multiple times to help identify padding/margin issues in the CSS as well as variable name clashes.

Before you go pushing out any new updates, make sure that you have all the elements named correctly with their default values set, if they have any, plus the pre-assignment of Content Classes to containers. By doing this you’ll save yourself lots of heart ache. It’s never fun to have to go through 12 Child projects and reassign a value to an element that you forgot. If everything is managed from the Parent your life will be so much simpler!

By setting all this up, you simply need to glance at each page to make sure everything still displays correctly. 

Once you’re done with the testing you can push the content classes out to all the child projects in one go, safe in the knowledge that it works. If something in one of the child projects breaks… duplicate any special cases in the Parent so you can test it again next time. 

There’s a catch in using the Foundation for development…

When you share Content Classes between projects you’re sharing it out as a full folder, rather than individual templates. This means that before you can push out any changes you need to be 100% certain that all the Content Classes in that folder are ready to go. If there’s only one or two of you working on the same site it shouldn’t be much of an issue.

For the most secure development environment, we’d suggest setting up a copy of the Parent and exporting the templates into the live Parent when they are complete. 

One last thing…

To save duplication, and server load/space, we’d suggest placing your media folders on the server, rather than in the database as it will give you much faster response times as well as easing the database load. It’s never a great idea to store binary files in a database.

Share and Enjoy:
  • Print
  • email
  • Twitter
  • Digg
  • Reddit
  • StumbleUpon
  • Google Bookmarks
  • del.icio.us
  • MisterWong
  • Facebook
  • LinkedIn

No related posts.

About the author:

Paul Smith Paul lives in sunny England and is now technical consultant for the new, UK based branch of ecomplexx. Apart from web stuff, Paul is also interested in photography and collecting/listening to music and is never seen without his beloved ipod!


5 comments for “That Parent/Child relationship explained”

  1. Hi Paul,

    We are planning on using this technique in our RedDot projects and I was just wondering if there are any pitfalls or caveats to watch out for sharing navigation manager functionality across sites? We want to share breadcrumb and intersection navigation functionality across all of our projects, do you just set up navman the usual way and have the navigation templates in the parent project?

    Many thanks,

    This is a lifesaving blog!



    Posted by Gareth | February 27, 2009, 12:03 pm
  2. Do you mean you want to share the navigation manager templates, or the output from these templates?

    If it is just the templates/functionality that you want to share, these work in the same way as content classes, you just need to remember to set up the navigation areas in each project as this information can’t be shared out between projects. This is where having a template child comes in handy as you can pre-configure this sort of information, saving you a lot of rework.

    Sharing the output of the navigation manager templates (e.g. your project sitemap, or level one navigation) on the other hand, can’t be done easily. If you need to share this sort of thing you’ll need to do things like publish the navigation of one project as an XML data structure and pull that into your other projects upon publication.

    Posted by Paul Smith | March 2, 2009, 11:49 am
  3. Yea, sharing the functionality was all that we needed, thats great, thanks for the reply

    Posted by Gareth | March 3, 2009, 6:22 pm
  4. Hi Paul,
    Thanks for this great write-up. This setup makes so much sense for certain situations as long as the caveats are clear. If the styling is cleanly separated from the HTML, so much the better.
    PS I had the good fortune to meet some of your ecomplexx colleagues in Leverkusen last year. Very nice bunch!

    Posted by Amanda Shiga | March 11, 2009, 3:54 am
  5. “It’s never a great idea to store binary files in a database.”

    Some Background info about this:
    Small binaries are delivered even faster from MSSQL than from NTFS. But that soes not make any difference, because all the Images are written to the image cache, first, before being delivered. So the speed advantage counts for uncached images, only. And this is quite a small difference even in large projects. In most cases, the database does already have regular backups. So there’s no need to care about backups. A strong argument for the database.

    For small files 10MB is NTFS, there is a dramatic difference. The fragmentation grows almost exponential. The problem is, that the standard tools for defragmentation do not work for binaries. In order to defrag, the table has to be deleted and created again. For CMS this means exporting, deleting and importing a project. I’m not as familiar with orqcle as I am with MS SQL. So I can’t tell how the situation is with oracle. At least for MS SQL it’s quite clear that large files/downloads should never be stored in database where small ones could.

    Posted by Boris Crismancich | February 13, 2013, 4:01 pm

Post a comment

Stay up to date! - Get notified about followup comments

If you don't feel the urge to comment but wish to stay in the loop:
Just enter your email and subscribe to new comments.

Subscribe without commenting

Recent Tweets

  • RT @AirKraft: Transport Canada breakout: they manage 80K pages and 300K assets with WSM(RedDot). Wow! #OTCW 2010-11-11
  • The RedDot usergroup session 'Future of WCM' is in National Harbor 7, now. See you there! #otcw 2010-11-11
  • RT @yttergren: @AirKraft: Calling all WSM(RedDot) devs: share your solutions on http://bit.ly/bgPIof EVERY solution can win an iPad #OTCW 2010-11-10
  • Come to the Solution Exchange session. Enhance your (#reddot) CMS project! Chesapeake 12, 3:20pm #otcw Looking forward to see you there! 2010-11-10
  • More updates...