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
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.
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.