Design pattern to invoke different business rules on presented UI elements

Question

I am working on a project that is developing a website application for 3 clients. All clients are happy with the base product that we are producing. 2 of them have some slightly different requirements - about the visibility of certain controls, different data binding to dropdowns, etc.

My question is - knowing that each of the 3 clients will keep coming with their own specific requirements, what is the best way of implementing these requirements at the UI??

I do not like the idea of having a series of IF-statements in each web form that I have that goes and manipulates drop-downs and control visibility individually. It simply litters my nicely organised files with custom requirements.

Can someone point me to a pattern(s) that could fit the bill?

Have a look at this simplified hypothetical example to see what I am talking about:

• A web form is populated with a drop-down that has 3 menu items (e.g. Home number, Business number, Overseas number); the drop-down is used to record a phone number type to a contact

• 2 of my clients, are happy to associate as many phone types to a contact (even if duplicates can occur)

• 1 client would like us to only show 'Home number' and 'Overseas number' in the dropdown if the current contact has already associated a 'business number' to his profile

I am thinking that I could possibly throw a notification event that contains the dropdown instance and a unique name for it. And then i have different 'client listeners' that consume these events and modify the controls that they get passed in separate classes - hence each client configuration is kept in nice clean silos.

Answer 1

I'd say you need to use State pattern, but it could be many other ways.

Answer 2

You don't really say what technology you're using. I will assume ASP.NET. If that's not the case, please update your question to include technology, as it can make a huge difference in what kind of solutions are possible.

You basically have two main approaches to this. You can create an abstraction layer for each and every control in your UI that validates itself against a set of rules. This is the most flexible, but it means you are adding the overhead of abstraction to every control, whether it needs it or not... and most likely, 95% of your controls won't need it, thus added overhead.

The other option is to require each page to run through various extra steps, probably by creating your own "OnXXX" events (OnOurCompanyPreInit, OnOurCompanyInit, etc..) in which you place extra logic for each client.

One of the drawbacks of frameworks like ASP.NET is that in it's quest to be highly flexible, it enforces a certain seperation of concerns that may not line up with the seperation of concerns you need.