Jeremy Davis
Sitecore, C# and web development
A while back I wrote up the faceted search example I'd presented at the London Sitecore User Group, and commented that ASP.Net WebForms wasn't really great technology for providing that sort of UI. I noted that it would work better if it could be implemented using Ajax-style UI.
Having finally had a chance to work out a basic pattern for building JSON web services using the sort of technology that's easily available in basic Sitecore 6.6 websites last week, I've now had a chance to get around to implementing a prototype of how the faceted search might be built with client-side processing.
Having looked at all the pipeline components for package generation last week, now it's time for a wrap up for this series.
As I mentioned in one of the earlier posts, as I worked through the code for this prototype, I changed my mind a bit on some of the basic architecture for the core program from the first post. I ended up re-working the configuration from the original idea and making the source control input and package saving output into configurable options.
In last week's entry I listed out the set of pipeline components required to generate a package. This week, lets have a look at what goes into each of those components and see how they interact with the configuration and source control data.
In the first two posts in this series we've looked at commandline parameters and fetching data, and then saving package files. This week, we'll look at how the fetched data can be transformed into the package data.
After last week's initial thoughts I've been beavering away on my prototype, and now have a working version. Which is good, as this series of blog posts wasn't going anywhere useful without that...
So this week I'll address the issue of how you can save XML for a package definition without having any references to Sitecore's DLLs.
Recently I posted an idea for a PowerShell script to extract the set of changed items in TFS needing deployment for a Sitecore project. I left the script at the stage where it gave a list of the files to package, but didn't actually give you a package definition.
Having done a bit more thinking about how that might be achieved, I've decided that it's probably worth a series of posts as creating a sensible solution to the problem seems a bit too complex for a script and a single post.
So for this first post, I'll sketch out the problem I want to solve and look at some of the basic code if will require. I'll flesh out the code an implementation over the rest of the posts – but I'm not sure how many there will be at this point...
There's quite a bit of material out on the internet about creating custom fields in Sitecore. But inevitably, when I found myself with a requirement to create one, I couldn't find anything particularly close to my needs. So here's another post about creating a custom field – maybe it'll be of help to someone...
Recently I found myself at the end of a sprint where a collection of developers had worked on a lot of different things in a pre-existing Sitecore solution. I needed to be able to deploy only the changes that were part of the sprint, and I had to generate a deployment package that could be installed by the client. And I didn't have access to any fancy tools such as Hedgehog TDS, that can be used to automate these things in other ways.
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:
NuGet is a really useful tool for managing external references for your .Net projects. It's also a tool that the Sitecore community are making good use of, with loads of useful Sitecore extensions available as packages. Plus it's been extended with the ability to deploy things into a Sitecore instance. Another potential use in Sitecore projects (that I've not found much discussion of) is for your references to the Sitecore DLLs themselves. I've been experimenting with this on some of my projects, so thought I'd write down what I've tried.
