Jeremy Davis
Sitecore, C# and web development
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.
Having been away on holiday recently, I've been doing a bit of catching up on the backlog of RSS-based reading that a week out of the office has generated. And one item stuck out at me as particularly interesting: some of the new features being discussed for the v6 release of the C# compiler. I came across a couple of articles discussing presentations given by Mads Torgersen (the C# Programme Manager) at the end of last year discussing some interesting feature proposals
Having spent a bit of time thinking about relative Data Source Locations last week, it struck me that the logical extension of this is to allow the data sources of components themselves to be relative to the context item. This is particularly useful when you need a branch template, that will include some child items of a page and you want to pre-configure the page's presentation to display these children via the data sources of UI components.
And happily this is a pretty trivial change for Sublayouts.
As someone famous** once said, with great power comes great responsibility – and the power of Sitecore's component-based page model puts a lot of responsibility on us developers to create a structure for component data sources that makes sense to content editors. The two most common patterns I find myself using are that of having a "shared content" folder somewhere in the content tree which reusable DataSource items live in, and having items as children of the component's page. When using the "shared content" folder you can easily set the DataSource Location field for your UI component to point to location where all the relevant data gets filed, but you can't easily do that if you want to have your DataSource items as children of the page. So you tend to end up leaving the DataSource Location field blank to allow the user to pick the current page as the place to create the new item.
This blog is a challenge to myself to try and write something technical once a week for a year.
Be honest people: how many of you have wasted a few hours of your life by accidentally clicking "Revert Database" when you meant to click "Update Database" after a long evening at the development coal face? I certainly have. And if you're like me and tend to serialise only the things you've changed in your project, then that means you generally end up with a dead instance of Sitecore.
