Ever since Sitecore 7 introduced the
ContentSearch namespace, more than half of the projects I’ve worked on have required me to update Lucene indexes from code. This topic has proven to be even more complicated than publishing Sitecore items programmatically! This post will examine some of the ways you can update the Sitecore indexes as-needed, from your code, and my opinions on when you should each each method.
When researching how to publish Sitecore items in code, anyone that has done a quick search around the web can tell you that there are many different approaches. Even a quick scan of Sitecore objects will reveal a lot of publishing related classes and methods. This produces a common problem: too many options, but not enough information about which way is “best” or most appropriate for your situation. That’s why I decided to write this blog post. Hopefully this will help you get a better grasp of the different ways to trigger an item publish programmatically, and how to choose the best method for your application.
The new “with Search” fields in Sitecore 7 offer a great way for users to select items from a large list of options. One problem is that these new fields have a lot of hidden potential that is not (yet) documented very well.
It seems that all of the advanced control that a developer has over these fields is hidden in the “Source” property. Rather than spew a lot of words at you, I’ll dive right in to the values and some examples.
We all seem to love WebApi. On the Microsoft technology stack, it is probably the most well-conceived method of building a REST-like web service. If you are building a Sitecore website, though, you may have a problem. Sitecore takes over most of the ASP.NET request cycle, which poses a problem for other ASP.NET technologies, including WebApi. That is not the end of the story, though!
If you would rather just skip all of the boring explanation stuff, then go install this Nuget package in your web project and get off my back!
The web conference at the University of Illinois was an excellent event! This conference was not my normal scene. Being a web conference, the sessions covered all pertinent topics from pure design and UX all the way to distributed real-time apps and TDD. Along with the heavier design focus, this conference was outside of my normal circle of friends. In fact, I didn’t know a single other speaker or attendee before the event!
This was a great growing opportunity, and I met some very engaging personalities! I highly recommend this event.
A couple of weeks ago I was at Nebraska Code Camp in Lincoln, NE. This was a very good event. All of the sessions I attended were excellent! In the hallway between sessions, and during the after-party, I met with some excellent individuals. The software development community is thriving in Nebraska!
After such a productive code camp, I thought I would post some highlights of the most useful and/or interesting things I have learned/re-learned. Unlike my last “what I learned” post, I am just going to include some of the highlights this time. This means you might have to think a little bit to digest these notes.
I’ve been writing software long enough to have developed a few opinions. Many of the practices and patterns that I have encountered have been great! Some have taken me down a dark, winding path. Here are a few that I find more bittersweet.
Test-Driven Development (TDD)
I am a huge proponent of TDD. It has saved my bacon a number of times, and has surely saved me hundreds of hours of troubleshooting and re-factoring.
What I Love About It
- My boss and team members like the higher test coverage
- Easier to communicate test cases and test plan ideas to QA
- Better idea about work remaining to complete a feature
- Greater confidence in re-factoring, since I know my tests will catch most bugs I might introduce
South Florida Code Camp 2013 is now over. This was a large event on the campus of Nova Southeastern University in Fort Lauderdale, Florida. The organizers did an excellent job, especially considering that there were about 80 speakers, over 1200 registrants, nearly 90 sessions and a blizzard in the northeast (which prevented a number of speakers from attending). A big thank you to Rainer Habermann, Dave Noderer and everyone else that was involved in making this event happen.
Since I have been attending a fair number of conferences and code camps, I have decided that it might be worthwhile for me to start sharing what I learn at these events. If this goes well, I’ll likely continue.
Here are my notes from the event. Some of these are things that I just learned. Most are things that I knew already, but enjoyed the reminder.
So here we go. What I learned (or re-learned) at South Florida Code Camp.
This next installment in my inside-jokes sequence is a very fun movie that my wife can’t stand. The only thing she likes from this movie is the logical method for determining if someone is a witch, which was screened and discussed in her college logic class.
As for me, this film is one of my favorites, and I can be caught quoting it frequently.
Monty Python and the Holy Grail
Monty Python and the Holy Grail is a movie that was made by the British comedy group that called themselves Monty Python. It follows the adventures of Sir Arthur of Camelot and his Knights of the Round Table as they quest to find the Holy Grail. Comedy ensues throughout their exploits. I won’t tell you how it ends, but it is both disappointing and humorous.
I get a surprising number of questions about when objects are disposed or collected. Usually people will have some limited logic to cleanup their objects (releasing file handles, removing references to large objects, etc.), and they don’t know when this logic will execute. Here is a little bit of insight into when objects are disposed and finalized. (If you are looking for more information about Disposable and Finalizable patterns, check this post)
When Does Dispose Execute?
The Dispose method on an object is only executed when it is called by the application. What I mean by that, is the CLR does not automatically call Dispose on your objects. If you don’t call dispose, it can result in a memory leak that does not get cleaned up until the process exits.
This doesn’t mean you necessarily have to call Dispose() explicitly. In C#, there are a number of times that Dispose() is called implicitly: