Previously on the Multi Tenancy series:

• Multi Tenancy - Definition and scenario.
• Reviewing Litware HR - P&P Multi Tenancy Sample.
• Multi Tenancy - The Physical Data Model
• Multi Tenancy - Extensible Data Model
• Multi Tenancy - Extensible Behaviors
• Multi Tenancy - Development Structure
• Multi Tenancy - Where do you put variability?
• Multi Tenancy - Scriptability and DSL
• Multi Tenancy - multi tenant apps and frameworks
• Multi Tenancy - Keep It Simple, REALLY Simple

Note, this is nearly the end as far as the theory and the constraints of Multi Tenancy applications goes, the next posts in this series are high level design, trying to touch all the points that were brought up so far, and then a big surprise...

So far, we have spoken only on the backend stuff, we haven't touched on how we are going to deal with the UI at all. We need to think about what kind of UI changes we need to handle.

Skinning / Templating

This include everything that is not actually functional to the application. That is, the customer wants their own logo instead of the default one, they may want different colors, etc. This is what I call templating or skinning.

Semi localization

I don't have a good name for this, but broadly, this include things like "our date format is", "our time format is", "we always enter FirstName, LastName", etc. This is mainly formatting issues, most of them are locale oriented, but there are a lot of similar issues that aren't handled by the locale.

As a simple example, in Israel, it is very rare for someone to have a middle name, so an application build to display the user's name as: {FirstName} {MiddleInitial}. {LastName} would look ridiculous ("Ayende . Rahien").

Different Presentation

One client may want something to be a report, another may want a tree, and yet another as a graph (please, don't ask). Very often, the issue of field ordering comes into play. For that matter, the customer may have no interest in some fields, and want to hide them. (see: middle name in Israel example).

Handling additional responsibilities

This goes beyond just showing / hiding fields, here we need to handle the extra fields that the tenant has defined. This can be interestingly complex, especially when you have thinks like related fields. This is interesting because we want to handle this without having to modify the core page.

Crazy Tenant Syndrome

I am not sure how to call this one, but this is usually the case when you have a big client that wants to have things their ways. In the old system, all text boxes were UPPER CAPS, so they have to be in the new system as well. They only sell to France and Germany, so they must never see the full countries list.

I am sure that you know the type, if not the actual situation.

Now, how do we handle all of this?

Again, divide and conquer is the only feasible strategy. We split the application into separate pieces, and deal with of them individually. The templating issue is fairly obvious, we will maintain a css / layout for each tenant. By the same token we can handle each of the other issues by putting them in their individual boxes, which we can then shuffle at will.

And yes, we will touch on the next post in this series.