Jeremy Davis
Sitecore, C# and web development
My work sometimes involves picking up projects that were started by other developers / agencies and making changes or enhancements. Sometimes the approaches used by the original developers can make these enhancements harder than they need to be. The HTML, CSS and Javascript of a recent project I worked on caused some issues that I thought were worth calling out to try and help developers do better work in the future.
NB: This post was written about Sitecore V6.6 – if you're using Sitecore 7.5 you should look at the updated version instead.
Ever gone through the steps to create a new Application in the Sitecore "Start Menu", but had it not appear despite refreshing? I wasted an hour of my afternoon scratching my head over this issue recently, so I thought I would write down what I went through in case anyone else hits the same issue...
A bit of a change of tack this week. Rather than writing about something I've been doing, I'd like to ask for your ideas on something I've been thinking about. This issue is way to complex to compress into a tweet to ask on Twitter, and it seems too opinion based to be asked on Stack Overflow. So I'll ask it here, in the hope that some of you clever people might offer your opinions. Comment below, tweet me, write blog posts in response, send carrier pigeons or whatever. All thoughts appreciated...
So here's what I'm thinking about: How do you set up your projects for development?
The other day I was having a conversation with a colleague who was bemoaning the lack of a fast way to paste a Sitecore item path into the UI and have the Content Editor change selection to that item. I suggested using the search box or the Navigate button, but apparently they weren't right. The person wanted to paste a link and have the content tree change without any other clicking about.
So, in the spirit of being a helpful co-worker, I hacked up a quick command extension to solve this problem. It's trivially simple, but I figured someone else might find it useful, or learn something that helps them...
Last week I talked about an approach to displaying template-related help fields in Content Editor. The last week has been a bit manic, so I've not managed to spend much time on extending these ideas, but I have a basic approach to displaying similar data in Page Editor. Quick one today...
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.
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.
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...
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.
