This post is just a bookmark for ourselves to this very interesting solution by Nick Wesselman to resolve the problem we have in Sitecore when adding multiple sublayouts of the same type into another sublayout.
Here is his solution: http://www.techphoria414.com/Blog/2011/August/Dynamic_Placeholder_Keys_Prototype
Even more goodies about Page Editor from Nick in this must-see post: http://www.techphoria414.com/Blog/2012/May/Sitecore_Page_Editor_Unleashed
In OOP/OOD, whenever we have a class (let’s call it the consumer) that uses a functionality provided by another class (let’s call this the provider), we have what is called a dependency. The consumer class needs a reference to the provider class in order to be able to access its functionalities. The easiest and most intuitive way to achieve this, is for the consumer to create an instance of the provider class calling one of the constructors of the provider (i.e. to “new” the provider).
Direct Reference
This creates a tight coupling between the consumer and the provider. Changes to the provider class might require changes to the consumer class as well.
In the introduction of the best-selling book Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995) – often referred to as the Gang of Four (GoF) book – the first principle that is mentioned is: “Program to an interface, not an implementation.” Erich Gamma, one of the author, describes this principle:
Once you depend on interfaces only, you’re decoupled from the implementation. That means the implementation can vary, and that’s a healthy dependency relationship. For example, for testing purposes you can replace a heavy database implementation with a lighter-weight mock implementation. […] So this approach gives you flexibility, but it also separates the really valuable part, the design, from the implementation, which allows clients to be decoupled from the implementation.
Translating this into UML, ideally we should get to the solution defined as a plugin by Martin Fowler in Patterns of Enterprise Application Architecture (P of EAA):
Program to an interface, not an implementation
This is actually only an ideal solution since the consumer class somehow needs to have a reference to an instance of the provider class and cannot directly instantiate the IProvider interface. A common solution is to introduce a factory in the mix, as show in the following UML diagram. The consumer calls the factory asking it to produce a concrete instance of the Provider class that implements the IProvider interface (the dotted line in the figure shows that, this way, the Consumer class gets a reference to the concrete Provider object).
Using Abstraction
This eliminates the tight coupling between the consumer and the provider, but introduces coupling between the consumer and the factory, therefore it is still not an ideal solution.
The generally accepted solution to this problem is to use Inversion of Control (IoC), in which object coupling is bound at run time by an assembler object.
Two common techniques used to achieve this are:
Let’s begin by diving into a code snippet that shows how to implement the service locator pattern:
public class Consumer
{
private readonly IProvider _provider;
public Consumer()
{
_provider = IoCContainer.Get<IProvider>();
}
}
Using the service locator pattern is easy. A developer just needs to ask the IoC container for a specific service class. The IoC container looks to see if the request class has been configured and based on the lifetime management rules for the class it will either create a new instance or return a previously created instance to the requester. The major drawback to using this pattern is your code needs to direct access to the IoC container, which could introduce a tight coupling between your code and the API of the IoC container.
There are many ways in which an object can get a reference to an external module at run time. The two most commonly used are:
public class Consumer
{
private readonly IProvider _provider;
public Consumer(IProvider provider)
{
_provider = provider;
}
}
public class Consumer
{
private IProvider _provider
public IProvider Provider {
get { return _provider; }
set
{
if (value == null) throw new ArgumentNullException("value");
_provider = value;
}
}
public Consumer()
{
// code using Provider
}
}
Ok, let’s stop here for a second. We mentioned above the Service Locator Pattern. Mark Seemann, author of the book Dependency Injection in .NET, also wrote an interesting blog post in which he declares that the Service Locator is an anti-pattern and should be absolutely avoided. In his words, the problem is that
the Service Locator hides the dependency from a class, causing run-time errors instead of compile-time errors.
Look again at the tiny example of Service Locator few paragraphs above, and imagine that the Consumer class is something that we didn’t code ourselves and that we got from a third party in a DLL assembly, without the source code. As soon as we look at the constructor, all we can see from the outside is that the class has a constructor with no parameters. When we try to call it, though, we get an exception at run-time, because we have not properly configured the IoCContainer before calling the constructor of the Consumer class.
After having more or less digested all the above, one question I have is: “What is the difference between using the Service Locator anti-pattern and using the Castle Windsor container?” (click the question if you would like to try to help me out)
And when I have a question like that, the first place I go to find help is StackOverflow. Over there, while searching for an answer, I stumbled into an interesting and very controversial answer by Joel Spolsky, co-founder and CEO of Stack Exchange, to a similar question (note: bold in the following quote is mine):
IoC containers take a simple, elegant, and useful concept, and make it something you have to study for two days with a 200-page manual. I personally am perplexed at how the IoC community took a beautiful, elegant article by Martin Fowler and turned it into a bunch of complex frameworks typically with 200-300 page manuals.
I try not to be judgemental (HAHA!), but I think that people who use IoC containers are (A) very smart and (B) lacking in empathy for people who aren’t as smart as they are. Everything makes perfect sense to them, so they have trouble understanding that many ordinary programmers will find the concepts confusing. It’s the curse of knowledge. The people who understand IoC containers have trouble believing that there are people who don’t understand it.
The most valuable benefit of using an IoC container is that you can have a configuration switch in one place which lets you change between, say, test mode and production mode. For example, suppose you have two versions of your database access classes… one version which logged aggressively and did a lot of validation, which you used during development, and another version without logging or validation that was screamingly fast for production. It is nice to be able to switch between them in one place. On the other hand, this is a fairly trivial problem easily handled in a simpler way without the complexity of IoC containers.
I believe that if you use IoC containers, your code becomes, frankly, a lot harder to read. The number of places you have to look at to figure out what the code is trying to do goes up by at least one. And somewhere in heaven an angel cries out.
And that, at least for me, is a clear point against IoC containers. I mean, come on, the fact itself that this answer is the most controversial answer on StackExchange shows that I am certainly not the only one out there that doesn’t get this… at least not yet :)
On the other hand, when I take a look at the following example, I start to see where IoC containers could be helpful:
IoC Containers are also good for loading deeply nested class dependencies. For example if you had the following code using Depedency Injection.
public void GetPresenter() { var presenter = new CustomerPresenter(new CustomerService(new CustomerRepository(new DB()))); } class CustomerPresenter { private readonly ICustomerService service; public CustomerPresenter(ICustomerService service) { this.service = service; } } class CustomerService : ICustomerService { private readonly IRepository repository; public CustomerService(IRepository repository) { this.repository = repository; } } class CustomerRepository : IRepository; { private readonly DB db; public CustomerRepository(DB db) { this.db = db; } } class DB { }If you had all of these dependencies loaded into and IoC container you could Resolve the CustomerService and the all the child dependencies will automatically get resolved.
For example:
public static IoC { private IUnityContainer _container; static IoC() { InitializeIoC(); } static void InitializeIoC() { _container = new UnityContainer(); _container.RegisterType<ICustomerService, CustomerService>(); _container.RegisterType<IRepository, CustomerRepository>(); } static T Resolve() { return _container.Resolve(); } } public void GetPresenter() { var presenter = IoC.Resolve(); // presenter is loaded and all of its nested child dependencies // are automatically injected // - // Also, note that only the Interfaces need to be registered // the concrete types like DB and CustomerPresenter will automatically // resolve. }
As it often happens, my quest brought me back to another post by Mark Seemann, and so I finally decided to buy his book “Dependency Injection in .NET” – if not for anything else, just to show my appreciation.
Turned out to be a very good decision, mostly because Mark has the uncommon talent to explain complex software engineering concepts in a way that would make them more or less understandable even by a person who is not a software engineer.
Just to give you an example, in the very first chapter, Mark revisits the common analogy between software interfaces and the electrical socket-and-plug model, and pushes it to the limit using it to explain all the following principles and design patterns:
And that’s just in the first chapter.
In the next chapter, Mark takes a simple but realistic example of a standard three-layer application architecture, implementing it twice. The first time he uses a traditional approach, what you and I probably have used many times – well, I don’t really know about you, but I know I did. The second time he uses Dependency Injection (DI). In the end, the architecture is completely reversed, as the final dependency graphs of the two implementations clearly shows:
Following his reasoning behind every architectural choice was an eye opening experience. Nonetheless, while the exercise was incredibly useful, at this point I really didn’t need him to convince me that using DI is better. I already knew that.
Remember, at this point, I still haven’t found the answer to my question: “what is the difference between using the Service Locator anti-pattern and a DI Container?” In other words, I need to learn more about using DI containers, in particular where to use them and how to use them.
I finally found the answer I was looking for in Chapter 3 of Mark’s book, and it turns out that it really is not that difficult to deduce if only we go back to the way Dependency Injection works. We have seen it at the beginning of this (long) post, when I showed the two most common ways of injection, Constructor Injection and Setter Injection. When we use DI, we defer the decision about selecting the dependency to the assembler class, right? And if the assembler class also uses DI, and it should, in order to maintain a loosely coupled architecture, it will also defer that decision to its own assembler class. And so on… all the way to the Composition Root. Mark says:
The longer you defer the decision on how to connect classes together, the more you keep your options open. Thus, the Composition Root should be placed as close to the application’s entry point as possible. […]
You shouldn’t attempt to compose classes in any of the modules because that approach limits your options. All classes in application modules should use Constructor Injection and leave it up to the Composition Root to compose the application’s object graph. Any DI Container in use should be limited to the Composition Root.
I think this is a good place where to close this long post. The quest continues, obviously, but I think I have shared enough information and resources to allow you to take it from here and continue on your own. I would love to hear your opinions and ideas in regards, so please leave those in the comments to this post.
Lately, I have been doing some reading. It all started last week when I decided to watch a few MVC tutorial videos on asp.net. That wasn’t enough, so, after some searching, I ended up reading the first six chapters of Programming ASP.NET MVC 4 by Chadwick, Snyder & Panda on oreilly.com. A very interesting read, for sure, especially because the book has been written for an audience that is – like me – already familiar with ASP.NET Web Forms – see Chapter 2.
Then, in Chapter 5, the authors take an architectural detour, explaining in details the implementation of the MVC design pattern employed by Microsoft in the ASP.NET MVC Framework. Let me quote a few lines, taken from that chapter, that really helped me understand how things work:
The original MVC pattern was designed with the assumption that the view, controller, and model were all within the same context. The pattern relies heavily on each component being able to directly interact with each other and share state across user interactions. Controllers would use the observe pattern to monitor changes to the view and react to user input. This approach works great when the controller, view, and model all exist under the same memory context.
In a web application things are stateless, the view (HTML) runs on a client inside of a browser. A controller can’t use the observe pattern to monitor changes; instead a HTTP request needs to be sent from the view to a controller. To address this the Front Controller pattern has been adopted. The main concept behind this pattern is when a HTTP request is sent; a controller intercepts and processes it. The controller is responsible for determining how to process the request and the result sent back to the client.
Later in that chapter, when the authors begin talking about Design Principles, the mentioned SOLID, an acronym of acronyms that describes a particular set of application development principles that drive proper object-oriented design and development. This captured by attention and lead me on an interesting tangent. I ended up listening to a very interesting podcast on Hanselminutes (transcript here) in which Scott Hanselman interviews Robert C. Martin (aka Uncle Bob), author of The Principles of Object Oriented Design, an article in which he introduced SOLID:
The five principles of class design are:
Single Responsibility Principle: A class should have one, and only one, reason to change.
Open Closed Principle: You should be able to extend a classes behavior, without modifying it.
Liskov Substitution Principle: Derived classes must be substitutable for their base classes.
Interface Segregation Principle: Make fine grained interfaces that are client specific.
Dependency Inversion Principle: Depend on abstractions, not on concretions.
The entire podcast is quite interesting and deserves to be listened a couple of times, for sure. But there was one part that I really found interesting, when Bob was talking about modeling languages. At some point Scott said:
Scott Hanselman: Yeah, and at some point, someone will do a switch statement and then they’ll spackle over it and pretend it didn’t happen and then it becomes legacy code.
Robert C. Martin: Wow, yeah, have you read Feathers’ book on legacy code? His definition of legacy code is code that’s not under test.
Scott Hanselman: Exactly.
Robert C. Martin: If you don’t have tests for it it’s already legacy code.
Then, yesterday night, I couldn’t fall asleep, so I ended up digging a bit more and listening to some related .NET Rocks podcasts:
At the moment I don’t have much else to add, since I haven’t really digested all this information, yet. Please take this blog post for what it is, which is, more or less, a way for me to bookmark all these interesting sources and to remind myself to come back to these soon for a deeper dive.
I have seen the following type of warnings in Sitecore logs:
7584 10:28:32 WARN Counter category 'Sitecore.Security' does not exist on this server. Using temporary internal counter for 'AccessDenied'. 7584 10:28:32 WARN Counter category 'Sitecore.Security' does not exist on this server. Using temporary internal counter for 'AccessGranted'. 7584 10:28:32 WARN Counter category 'Sitecore.Security' does not exist on this server. Using temporary internal counter for 'AccessResolved'. 7584 10:28:32 WARN Counter category 'Sitecore.Security' does not exist on this server. Using temporary internal counter for 'ModifyRequests'. 7584 10:28:32 WARN Counter category 'Sitecore.Security' does not exist on this server. Using temporary internal counter for 'ProgrammaticDisabling'. 7584 10:28:32 WARN Counter category 'Sitecore.Security' does not exist on this server. Using temporary internal counter for 'ProgrammaticEnabling'. 7584 10:28:32 WARN Counter category 'Sitecore.Security' does not exist on this server. Using temporary internal counter for 'ProgrammaticUserSwitch'.
If you want to verify if your logs have similar errors simply search for the string “Using temporary internal counter for” in your latest log file.
This seems to happen a lot when an older version of Sitecore gets upgraded. Today I happened to stumble into the solution!
To resolve this problem:
1) Download sitecorecounters.zip from Sitecore at http://sdn.sitecore.net/upload/sdn5/faq/administration/sitecorecounters.zip
2) Unzip the archive.
3) Run the SitecoreCounters.exe program on every production / QA server and on every developer machine in order to re-register the Sitecore performance counters.
Often the sample workflow provided with Sitecore can be all you need, but often times the client wants much more flexibility, especially when dealing with multi-regional or multi-departmental organizations. In our case these were the workflow states and commands that were required:
Workflow States and Commands
This is quite self-explanatory. To function, the workflow above requires the creation of 4 roles: an Editor role, an Approver role, a Proofreader role and a Publisher role.
What complicated things was that the client wanted a separate set of roles for each of their regions. In other words, with a naive implementation, we would have needed to create a quite large number of roles:
total number of roles needed = 4 x num of site regions
A post by Rick Cabral inspired the following implementation, which ensures that each of our security roles addresses one and only one of the following concerns:
Using this approach we need only:
So these are the roles that we have create to handle the workflow:
Security Roles to handle Workflows
Let’s take a look in particular at the Content Editor settings in the Security Editor, to see how to set correctly access levels:
Content Editor access levels
This allows the editor to work only with items that are in Draft state and it gives the editor access to be able to Submit for Approval.
Content wise, here are the security settings for the Access to Region 1 security role:
Security settings for Access to Region 1 security role
Then, if we want to create a user that is a content editor just for region 1, all we have to do is to make the user member of both the Content Editor role and the Access to Region 1 role:
User Settings for Content Editor for Region 1
a thousand lines of code 