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!
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:
Through my discussions with various developers, I have noticed a common theme when it comes to disposing objects. Most developers are confused, or at least unclear, on why and when to use dispose and finalize.
Let me start off with this: The purpose of dispose and finalize is the same… to improve the performance of the application and the host system. You don’t need to implement either. When the GC runs, unused managed memory will be reclaimed. When your process exits, the entire process’s virtual memory will be released. When the system re-boots, any open native handles will be closed. Dispose and finalize are two patterns that make it easier for your application to be a “good citizen,” releasing memory as soon as it is no longer needed and closing handles as soon as you are done with them.