Why does my code get screwed up?

Why does blogger.com screw up my code? Does anyone out there know a good way to post code?

I've yet to find a good way to post an attachment.

The Barrier Method

They say it's the only safe way... use a barrier method every time.

Seriously, though. I was pleased to see that .Net 2.0 contained an implementation of Semaphore. It contains a lot of cool stuff. Something it doesn't have, though, is a barrier. Barriers are a synchronization tool that can be used to ensure no thread starts working until the desired number of threads are ready.

A good real life analogy for a barrier is the starter in a race. The starter makes sure that all of the runners (threads) are at their marks. When all of the contestants are ready, the starter fires his fake pistol and they're off. That's what the barrier does. It's not the most commonly used synchronization tool - I use it mostly in tests - but it can come in handy.

Below, I've implemented a barrier as a wait handle. I commented it a little but, frankly, I'm tired. It should be pretty clear how it works.

Google blogging screws up one's code, so I've moved the example to a seperate text file.

WebPart Skins & User Controls

Today, we're developing a web part. This web part has the requirement that administrators be able to edit the user interface through the web UI. Since more than instance may be deployed to a single web site and one web site can span more than one host, we cannot simply provide an editor for a file.

What we really need is the ability to treat one of our web part's properties as a user control. Of course, user controls are useless if they can't have scripts or databinding in them, so we cannot simply use TemplateControl.ParseControl; we have to use LoadControl. Now we see our problem: LoadControl requires a file but we want to persist our control as a property.

The solution ends up being pretty simple: We store the body of our skin as a property of our web part with freshness data. In the solution provided here, our freshness data is a Guid and the body of our skin is the text portion of a user control (we are foregoing code-behind, for now). Every time an instance of our web part is rendered, it tries to load its skin from a cache directory (which is also specified via property) using the Guid as its name. If the file does not exist, we create it.

The result is, effectively, every time an administrator saves a change to a web part, a new use control will be created on every host. Since the user control is loaded from a file, it will get the advantage of ASP.NET's caching & compilation infrastructure; meaning it can have custom code and data-bindings in it.

Unfortunately, Google Blogs screws up source code. You can download an example here.

A nightly job can clean up old items by simply deleting all the files in the cache folder: the ones worth saving will get regenerated the next time they are needed anyway.

"Why?" you ask, or maybe, "Why not just use files?" I cannot answer that. I mean: I know the answer; I just can't give it to you right now. There are some out there who know why already. To anyone who asks "why" the only legal answer I can give you is "you'll see."

Skin me. Skin me, my friend.

Skin me again!

Okay, today I'm going to give you a little example of skinning. This is a super-simple case. Here, we have a controller class called "SquareIt." SquareIt lives in an assembly named "SkinExample.UI" and inherits from System.Web.UI.Control. There is also an interface ("ISquareItSkin") that serves as the contract between the SquareIt class and its skins.

For simplicity's sake we are just dealing with skinning. We are not separating any business logic into separate classes.

Let the code speak for itself.

Let's talk about skinning

No, not the "it puts the lotion in the basket" kind: the "my UI and business are loosely coupled" kind. In this post we are going to discuss a good way to break the user interface out of your system: Skinning. When you make your application "skinnable," you allow users to load new looks-and-feels at run-time. There is a Skin Pattern out there. Unfortunately, there is no definitive authority on what, exactly, the Skin Pattern is. There don't really seem to be any good authorities on what any pattern is, for that matter. I am going to talk about a way of implementing Skinning, not the way.

Skinning is little more than a fancy name wrapped around the Model-View-Controller pattern. Why that's not called the "Model-Controller-View" pattern is lost on me. Really quickly: Let's not get true skinning confused with ASP.NET Themse or Skins, which solve the problems that css should have. If you are one of those people who is in to service-oriented architecture, think of the skin as just another service: the "interface with foreign actor" service. If you are into MVC, think of a skin as a loadable view with a few extra restrictions. If you are someone who doesn't need fancy-pants terminology wrappped around everything you do then, well, good for you... we could probably be friends.

Consider the leftward class system. There are a number of business objects which represent the "Model." If you are an SOA guy, then they are your various data and business intelligence services. There is a controller that coordinates between the business objects and the skin. Finally, there are skins which compose the "View." For SOA people, the skin is just another service that allows foreign actors to communicate with a system.

There are slight differences between making an application "skinnable" and using the MVC pattern. For one, in the MVC pattern, the view is allowed to access the model. In the implementation of skinning proposed here (and in any instantiation of the Skin Pattern worth its salt, really), the Skin (the View) is not allowed to talk with the business objects (the Model). Also, while skins cannot provide new functionality, they are able to hide existing functionality. Additionally, there is a difference of intent. Most often, I have seen MVC used to create modularity between the presentation, the business intelligence, and the data; the ultimate goal being maintainability. Skinning, on the other hand, generally takes advantage of modularity to allow run-time selection and/or customization of the UI; the ultimate goal being flexibility.

In the diagram above, you should see an ISkin interface. This interface should serve as a contract between the controller and the skin. The contract defines three means of interaction:

• Messages from the Controller to the Skin
• Messages from the Skin to the Controller
• Shared data

Messages from the Controller should be passed to the skin via method calls. Messages from the skin should be posted via an event. Shared data should be referenced by properties. Once you have defined the contract between your controller and its skin, you may then implement the skin and controller in whatever order and manner you choose. The end result is that you have a modular system in which new user interfaces can be deployed independantly of the application itself.

A code example of how this might be implemented will be posted in the near future.

PolyLoginView

This is another variant of LoginView. This one is for building a role-based dashboard. It instantiates the template for each applicable RoleGroup. A RoleGroup is considered applicable when all a user is in all of its roles.
Of course, since Google Blogs screws up my code, I have to put it here.

ScopedLoginView

Okay, here is a LoginView that is not bound to the default provider. Of course, I would like to be able to just post it to the web, bug Google Blogs does not support that, so I have to put it here, instead.

Is Java on its way out?

Of course not. I hate stupid questions like that. "Is .Net dying?" is just as idiotic.

People who ask questions like that are good arguments for eugenics. There. I said it. If you call into question the short-term survivability of a platform as vibrant as either .Net or Java, you should be sterilized. As should all of your offspring.

...possibly anyone who didn't slap you when you initially asked the question.

Okay. That's out of my system. Pending a disclaimer, let's ask some real questions.

DISCLAIMER: I am not an authority on Microsoft's motives. I am not an authority on anything, for that matter.

Question #1: A common pattern, in today's world, is to program to an interface and use an abstract factory, service locator, etc. to obtain instances thereof. How come most of the .Net framework does not use this pattern?

Answer #1: You won't like the answer.

Question #2: No, seriously, tell me!

Answer #2: Because you make them cry. People, generally, don't understand things. For instance: beyond the basics, I don't know how a car or a lung works. The world is big and scary. It is filled with monsters, wars, tragic deaths, and scary spiders. These and a myriad other things all drive the average person - including the average programmer - to simply "tune out." Having to explicitly use an abstract factory or other "servicey-locatory-type-thingy" is an extra step that half the people just won't comprehend and the other half will question the validity of. Using new, on the other hand is comfortable; It's easy to read and understand.

Fortunately for everyone, those tricksy hobbitses at Microsoft figured out a way to build a "servicey-locatory-type-thingy" directly into the .Net platform: binding redirection. Through this artifice Microsoft can update a .Net framework assembly without disrupting dependent assemblies. That's right: Because of binding redirection, you can sit on your couch, drink your pepsi cola all evening, leave the reality TV shows running while you sleep, then drive your SUV to work and keep using new without having to worry if Microsoft is going to update an assembly on you.

The bottom line is this: They did implement a dependency inversion mechanism it's just too transparent for most people to see and they did it that way because they don't trust you. I don't trust you either but that's probably not your fault: I know the coffee machine lies but it's words are like honey... I just get all mixed up.

Question #3: Should I just use binding redirection?

Answer #3: If you have to ask, the answer is probably "no." There are reasons to use it and reasons not to use it. Let's go over them together as two friends holding hands:

Good points:

• You can apply it to applications you have already deployed
• It allows for intuitive construction of objects using new
• It requires no maintenance

Bad point:

There is really only one bad point. Reliance on binding redirection as one's primary mechanism for dependency inversion hides certain design problems until after the fact. If you have to conform to a service location mechanism, you are more likely to think about where boundaries between services and consumers might be. Likewise: you are more likely to use interfaces to address a class hierarchy than actual implementations.

The System.IO namespace is a good example of the downfall of reliance on binding redirection. All streams must derive from System.IO.Stream, which is monolithic and does not capture the essence of "streamness." Instead, because .Net's linear inheritence is so limiting, it attempts to provide hooks for all features that a stream might offer. If you need a concrete example, take CanTimeout, ReadTimeout, and WriteTimeout. In a proper, interface-driven, class system, one might break these out into a seperate interface (one that implemented IStream); it is likely that CanTimeout would retire altogether.

Again, this is not a failing of binding redirection, it is a failing of the class-system designer. Binding redirection is just an accessory.

I tend not to use binding redirection and, when I'm helping an organization set its infrastructure up, I recommend against it. A custom solution is easy to implement (more on that later... I'm tired), easy to maintain, and begs certain questions that historically people do not ask.

Why, god? Why?

All I ever wanted from you was... ten... million... dollors!

Seriously. I'm smacking my head up against a wall looking for a way to tell my LoginView which RoleProvider to use.

Well, not really. It is annoying, though. I guess we'll just have to write one that is complete.