Site Studio Tips, Tricks and Hacks

I thought I would throw together a list of some of the things I do when setting up or even working with Site Studio.  Nothing too crazy or ground breaking, just some things I do to make life a little easier while I’m developing.

Use Real Names for Section IDs

Starting work on a new site, my first step is to go through and set up the known folder structure of the site.  This usually only takes a little while, but it helps me visualize how everything will work as I’m developing.  One thing that’s very important to me during this step and really throughout the build is to ensure I’m using logical names for the section ids and not just the default numerical ones that the designer will assign.  Down the road when debugging fragments or even reviewing content in the repository, numbers as section ids can be very confusing and will probably cost more time the it takes to just give them logical names.

Create a Templates Folder

When I am building out the site’s folder structure I also like to create a contributor-only templates section.  There I add a section for each template the site will use, actually creating the template and assigning it to the section during the process.  Often I will break up the template sections by how they are used, adding primary and secondary template parent sections.  If I have any html ready, I paste it in to the templates, adjusting any css, javascript or image paths during the process.

The templates folder allows me to get all my templates in and assigned to the site, but in a central location.  Templates can be added as a site asset, so this is a bit redundant, but having them in a folder allows me to assign region content, test custom properties and potentially navigation as well.

Use Fragments for Images, Javascript and CSS

When I start work on a site I usually have the luxury of receiving all of my html, css and some of my javascript pre-built from our user experience group which means I am not doing any serious HTML development in Site Studio other then some simple tweaks.  Since that’s the case, there’s no good reason for me to load what could be hundreds of individual site assets in to the content server.  It’s much easier just to load each set of assets in to fragments and then check them in that way.  In addition you can preserve any folder structure the assets already have, making tweaks to the template html a bit easier too.  Loading each asset individually is perfectly fine, but I thinks far easier and a little cleaner in the content server to load them in fragments.

When you save the fragments it’s assets are written out to the weblayout/fragments folder.  Once those assets are there, I just create a single “head” fragment which references the nessecary items from css and javascript assets, never actually referencing the css or javascript fragments.

One Fragment per Library 

I’m a fan of creating a new library for each fragment in my site.  I’ve done this differently in the past, creating more contextual libraries with multiple fragments, but I’m much happier now with the one fragment per library way.  Right off it’s much easier to manage fragment development with multiple developers.  Multiple fragments in a single library means that one developer can check out a library at a time thereby preventing other developers from working on other fragments in the same library.  

My biggest reasoning though has to do with change management.  If there are multiple fragments in a library all of them must be production ready to deploy.  You easily can find yourself in a situation where a change is occurring on one fragment, when a bug or another emergency change needs to happen on another.  If all the fragments are in the same library it can become a confusing mess.  If you stick with one per library you may have a few more libraries in the content server, but you’ll also have a great deal more flexibility.

Debug that JSP

This next part can be a little tricky and from an Oracle perspective is probably a bad practice.  Generally whenever I set up a new development environment also set up eclipse to debug the content server as well.  Bex Huff’s book “The Definitive Guide to Stellent Content Server Development” details how to configure eclipse for debugging so I am not going to cover that process here.  What I will talk about though is that if you are running a version of Eclipse with JSP support, you can also debug JSP fragments and layout templates just as easily as filters and service handlers.

This sounds great, but you have to remember that if you’re debugging and editing your fragments through eclipse, ultimately you’re also doing it in the content server’s area of the file system.  If you’re not careful this is an excellent way to loose your work.  If anyone else edits your fragment library or if they deploy your fragment through the Site Studio fragment administration page, any changes you’ve made on the file system will be immediately overwritten.  To counter the threat of loosing my changes, I make sure I always check out each item I’m debugging and frequently save my changes back to the fragment using the designer.  All that said, being able to debug with eclipse can make development so much easier the rewards far outweigh the risks. 

To set up JSP debugging, first follow the steps in Bex’s book to set up your eclipse environment and then just link the weblayout folder to your content server project.  From there you’ll find your fragment JSPs in the weblayout/groups/[your jsp enabled security group]/WEB-INF/fragments/[fragment name] folder.

About David Roe

Thanks for visiting, my name is David Roe and this is my blog. I work for Ironworks Consulting as a technical lead/architect in our enterprise content management group. My primary focus is implementing Oracle Universal Content Server, which was formerly known as Stellent Content Server. Prior to focusing in Stellent, my work centered around .NET integrations with other content managment systems as well as content management systems built on the .NET framework. I plan on keeping this blog mostly technical in nature. I’m not really one for the Coke vs. Pepsi debates, so plan on seeing quite a bit of ”how to” content. Please feel free to download and use any of the code examples available on the site. As you might imagine none of it is supported or we need a disclaimer? I do ask that you leave any references to me or this site in the comments though.
This entry was posted in Fragments, JSP, Oracle, Site Studio, Stellent. Bookmark the permalink.

6 Responses to Site Studio Tips, Tricks and Hacks

  1. mikeyc says:

    I really disagree about naming your nodes. My site has dozens of subadmins with access to nodes. They can’t even assign proper URL directory names! Once an ID is used, it cannot be reused… and everyone wants to use “about”. Stick to auto-generated nodeIDs and just chuck in some code to identify the label whenever required.

  2. David Roe says:

    Hi Mike,

    Thanks very much for your comment, as you can see the site doesn’t get much feedback so I’m pretty excited when anyone responds.

    To your comment though, I think that’s an excellent point in relation to dozens of sub-admins. I can see how could quickly become a bear to manage.

    Still I think for the majority of sites having logically named IDs can help a great deal when it comes to debugging issues and development.

  3. Kyle says:

    Another good tip I like is to really make use of Custom Section Properties. This can help you reuse layouts/fragments when you may otherwise need a new one. Things like queries can be defined in the section properties so that the same layout can have different dynamic list results.

    It’s also handy for defining meta tags that may be applicable per section of the site.

    There’s also a way to define site-wide properties using it. See doc 445449.1 on for a how to.

  4. Anonymous says:

    I just surfed in and found your site, I really enjoyed the visit and hope to come back soon. nice Site!

  5. Pierre says:

    I David, i’m new in UCM and i really appreciate your comments. It Help me out a lot. thanks

  6. Troy says:

    Hey, just found your blog. I find your 1st two tips very interesting, as I started doing both of these to some degree in the last few months.
    The logical naming of nodes is something we have always done. I disagree with Mikeyc, finding unique names is easy with a standard. No two nodes are identical anyway.
    The ‘frag as a file store’ is something we have started doing here recently, and DAMN is it handy. Previously we had site wide images, CSS and JS checked in as content. This made editing them a nightmare! Checking out, editing, checking in, review changes, repeat.
    A contractor set up the JSP -> eclipse link for me a while back, I will have to check that out again sometime.