Friday 16 November 2007

To Customise CMS or Not

I have seen a lot of discussion recently on whether to customise the Out-Of-The-Box (OOB) functionality directly or not.

What I mean by this is whether, as a customiser, you should edit what is given by Pivotal (in terms of Client scripts / App server rules / table fields / queries) or should you create your own, using the base as a reference or even referencing them directly with an additional layer (for Appserver rules). There are Pros and Cons for each method, which I hope to summarise below, so you can make your own decision.

Direct Editing of OOB
  • PRO: Quicker turn around for any code changes (as you don't have to create anything you don't have to)
  • PRO: No additional dlls to cause issues
  • PRO: Speedier performance as not calling 2 dlls to do the same function
  • CON: Upgrades are more difficult, as you need to be careful not to replace any customised code
  • CON: Difficult (unless properly documented) to know what is your customisations and what is OOB when something is wrong.
Adding to OOB
  • PRO: Only use the bits of OOB that you need : if you don't want to use the OOB method for delete contact, implement your own.
  • PRO: Distinction between what is your customisations and what is OOB
  • PRO: Upgrades / CMS Hotfixes are easier to implement as you have not touched the OOB.
  • PRO: Ability to use .NET Appserver rules for customisation even though the OOB is VB6.
  • CON: Why alter things that are not broken? If you need to change the save form call in an Appserver, you will also have to provide functionality (or at least pass to the OOB) for Add / New / Delete / Execute etc.
  • CON: Slower execute time as you are calling 2 dlls to do the same functionality that can be achieved by one. This is a negligible one now adays, but worth considering if you are doing frequent calls to an Appserver.
I admit that I am firmly in the Adding to OOB camp, as I believe the benefits far out way the negatives. This is also the Pivotal method. Not saying this is correct, but I always take guidance when it comes to the customisation of an application from the writer where I can. The time taken to create a pass through Appserver rule in .NET or VB6 is negligible, and I would rather do this than comment out huge chunks of code that I don't want.

I also apply this rule to Client Scripts / Queries / Forms etc. The first thing I usually do when customising for a client is take a copy of the Contact form, save it as Company Name Contact, and update security so the new form is the default. Same with the Form script and any scripts I need to alter that are referenced by the form. The Appserver, I will create a Company Name Contact .NET project and pass through to the original for all the methods (SaveForm, AddForm etc).

Hope this helps with any new people starting up in Pivotal development.

No comments: