Sean Holmesby

.NET and Sitecore Developer

By

Powerful ways you can save on Sitecore development time

Working on Sitecore? How much time are you actually wasting, instead of getting work done?
Maybe you’re a Slack-er.
Maybe you just think, ‘that’s how it is’ and you do things the hard, time-consuming way.
Or maybe you actually want something better…..

Anyone that knows me in the Sitecore community, knows my love for the tooling and processes of Sitecore development. Working at Hedgehog, it’s something we are constantly analyzing from our own projects, and something we are always trying to improve on. We aim to keep development costs down on projects by not cutting features, but by working better. This leads to happier clients, who get more bang for their buck when hiring a Sitecore development team.

So how do we do it?

Well, at Hedgehog, we not only do client work producing websites, but we also dedicate people to work on tools and modules that help improve things. Most of the time, these tools are born out of the frustrations that we’ve found with the paradigm, but also from the general murmurs from the community. Having hands-on experience with the problematic stuff in Sitecore development, we’re in a position to try and find ways to improve it. Sometimes this leads to shared source modules that we create, sometimes it’s examples of projects for people to see, and sometimes, with enough demand, it can result in full-scale, commercial products with 24/7 support and dedicated development teams.

TL;DR

  1. Use all the productivity features of TDS Classic
  2. Use Sitecore’s own tooling
  3. Use what others before you have already created
  4. Don’t wait for Sitecore’s lengthy app pool reload….use ZeroDeploy instead!
    Sitecore is Loading

Read More

By

Speed up TDS Code Generation time

TDS 4.0 introduced Code Generation as one of it’s features, and I’ve been using it on projects ever since. The fact that you have classes generated based on your Sitecore templates, means the time spent to hand roll these models is eliminated.

When setting up a TDS project with Code Generation, there are actually multiple ways this can be achieved. If you’re using Glass Mapper, you can follow the setup here. If you’re using Fortis, you can follow the setup here. Or if you are doing anything else, TDS allows for that flexibility as well.

One thing I do differently from most of these instructional posts is I set the Base Project Transform File in a different way.

When setting up Code Gen on a project, most people set the Base Project Transform File setting on the project properties page.

01-project-properties-page
This setting means that all of your items are subject to the processing of the .tt file.
Now, typically in that file, for instance in GlassItem.tt, there is a check to see if the item is a template, and if not, skip over it…..which is what’s required in most cases because you might typically only generate code for templates.
However there is still the little overhead of running the TT file on the item, and doing the check.

What I do instead is I keep the Base Transform File setting blank, and instead navigate to the root folder of the items I want to generate code for.
In the case of the LaunchSitecoreTDS project, this is the /sitecore/templates/Launch Sitecore item.
Then I open the properties on that item, and set the Code Generation Template to the TT file.

02-item-properties

Note: I also typically set the Namespace property here as well, also leaving it blank on the project properties page.

What this means that code generation processing is ONLY run on items below this folder, and not on all other items in my TDS project. This is perfect in the case where I’m only generating code based off my templates, and nothing else. No time is wasted on the content, layouts, media library or system items.
Using this setup, I manage to save a little overhead processing time when performing Code Generation, meaning I can get back to my code a little quicker.