Jeremy Davis
Sitecore, C# and web development
One of the challenges of building sites with Sitecore can be making sure that your content editors understand the purpose of each template and what data they're supposed to be filling in for each field to build up their site. This can be a challenge for complex sites – the data model required for building a complex and feature packed site can sometimes be difficult to explain to non-technical editors.
Historically I've usually tackled this problem though documentation and training sessions – but it struck me the other day that Sitecore itself should be able to help too.
So I've been experimenting with the basics of a really simple prototype for explaining templates. I'll explain a what I was thinking about for Content Editor this week, and hopefully offer some ideas for adding similar behaviour to Page Editor next week.
Whilst it's nice and easy to create JSON services for your front-end JavaScript if you're working in ASP.Net MVC, things can be a bit more difficult to wire together if you find yourself with project requirements that force you to work with the older bits of ASP.Net. Getting the JSON inputs and outputs to work can caused me some head-scratching.
Having had to make this work recently, I thought I'd write down where I ended up after searching Stack Overflow and MSDN...
I've talked previously about how you can improve your content editors' understanding of where things live inside your Sitecore content tree by making use of relative queries to specify where the editing UI finds things. You can do it Data Sources.
Logically, you'd assume that if a relative query works for a Multilist field in a normal template, it should work in a Parameter Template too? Well, if you set up something like this:
I was creating a quick package to transfer some content between Sitecore instances the other day, and happened to scroll down to the bottom of the Metadata page in Package Designer. Not for any real reason – just some over-enthusiastic scroll-wheel action. But when I looked at the dialog, it struck me that there were two fields here I'd never paid any attention to before:
Last week I spoke at the London Sitecore Technical User Group, and discussed my experiences working on a project that had to provide a Faceted Search UI in Sitecore 6.6. As part of my example, I talked about how you can build Facets using Lucene when you don't have access to the newer search APIs available in Sitecore 7.x, and about how you can make your search UI configurable by editors to improve their user experience. And I said I'd post my example code and explanation. So here goes:
The third part of this series is to look at how we can add images to our XML Sitemap files. We've looked at the configuration and the basic code to get entries into Sitemap files in the first two posts.
Getting images into the sitemap requires two things: First specifying some rules for what images to include, and secondly some code to extract those images from the content and write them into the index files. The code to deal with images that are specified in fields on the web page item is easy – but we also need to deal with the situation where the image is referred to by a component that has been dynamically bound to the page.
Last week we looked at the stuff to create in Sitecore to configure a custom sitemap generator. This week we'll carry on and look at the basic proof-of-concept code that can be used to process that configuration and generate a sitemaps and sitemap index files. It's another epic post...
Sitemap files are a requirement for most websites these days. They help SEO by ensuring that search engines index the files and images they might not otherwise find, and that you think are most important. Whilst there are assorted pre-built add-ons for Sitecore that can help with this, that's no fun. It's much more fun to build your own...
Real work is getting in the way of blogging time at the moment, so I'm going to break up my investigations into this into three posts. This week I'll look some requirements, core configuration and overall algorithm. The next part will look at the core code. And the final one will look at adding image data to the sitemap files.
The projects I'm working on at the moment are largely stuck using older versions of Sitecore. Whilst our friends at Sitecore UK would love us to upgrade to new versions as soon as they appear, for some of my clients that is not practical for a variety of reasons. However some of the features in newer releases of Sitecore would still be useful in these projects – so recently I found myself quickly coding up a simple version of something like the dictionary domains functionality in SC6.6.
The behaviour I needed to enable was to be able to have separate dictionaries for different aspects of the site – to be able to move dictionary entries away from their standard location in
/sitecore/System/Dictionary. You can do this by providing a custom "translate" method that your code can call to turn a dictionary item path into some text.
Recently I looked at removing aliases when their owning items were deleted. I noted at the end of the post that the code ended up with some duplication in it. Duplication is generally a bad thing in code – copy/pastes of code tends to diverge over time and introduce bugs. So ideally we'd work out a way to get rid of the duplication, and reduce the set of methods our class needs.
Having been reading a bit on functional languages and F# in particular, I was thinking about how it can be done by passing code as parameters to more generic methods.
