Jeremy Davis
Sitecore, C# and web development
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.
In these days of standards compliance, most of the time you want the mark-up stored in your Rich Text fields to be well formed XHTML – which is exactly what the editor for these fields should give you. But what can you do if you come across a scenario where you don't want the mark-up to be changed by the editor for some reason?
Recently I attended the developer upgrade training course for Sitecore 7, which was an interesting (and busy!) day learning about what's been changing in Sitecore in recent releases. But in amongst all that information, there was an interesting admission – Sitecore's training has moved away from the "stick your Visual Studio Solution in the Sitecore website folder" model that had jarred with me when I first did their training.
I didn't really like this model when it was taught at the original Sitecore training I attended a few years back. Before Sitecore I had done all my development work with my solution folders outside of the IIS sites. So the model I adopted for development when I started my first real project made use of MSBuild instead. (Rather than the Visual Studio Publishing wizard that the latest training discusses) So I thought I'd write down a few of the things I'd tried for setting up solutions, in case these of use to anyone else...
Quick (and not Sitecore specific) one today, as I've got a very busy week in the office and it's eating into my time for blog posts. To make a break from a few weeks of writing about navigation patterns, here's an idea about something I've found a surprising number of developers don't know about: "Protocol agnostic" or "Schemeless" URLs.
Working on some components for a client's site recently, it struck me that there were circumstances where it would be helpful to editors to allow the "Select Associated Content" dialog to have multiple options without just showing the whole content tree. Scenarios like having both a global shared content folder and a sub-site specific shared content folder that editors could choose between, for example. Something that looked like this:
I hit an issue recently where it was necessary to get direct access to the Web Forms for Marketers database. The code needed to do some custom processing of previous form submissions in a Sitecore website, and it needed to process so much data that the public APIs for WFfM were too slow to use. Slightly annoyingly, the connection string for WFfM is not added to the the standard .Net
config element, but is stored in the custom provider configuration in WFfM's forms.config file:
Last week I looked at how to visualise aliases in the Content Editor, based on a requirement from one of my clients. The second part of the work I was considering here was how you can automatically remove any aliases related to an item when you remove that item. What I wanted to achieve was having the system prompt you to ask if you want the aliases removed whenever you delete an item that has aliases attached. Something like:
Recently a client I work for came to me with an interesting question. Their Sitecore-based website makes heavy use of Aliases to set up shortened URLs for publicity purposes, but they were finding it difficult to manage the large number of aliases they were creating. Their key issues were remembering which pages had aliases defined, and remembering to delete aliases when they removed the pages they were related to.
For a while now it's been possible to configure Visual Studio to allow you to step into the publicly available source code for the .Net Framework, but a post on Channel 9 today provides information on some new ways to get at this fascinating information MS are releasing.
