Im a relative newcomer to the world of UCCX and am enjoying building scripts and applications. In my experience so far in the real world and after speaking to people on the UCCXD course there seems to be an 'old-school' and 'new-school' approach to scripting. The tutor from the course was of the 'old-school' category who preferred to write scripts for customers on an individual basis, making them as simple or as complex as they need. This meant the customer got what they wanted and the script is easy to follow to debug. It did mean that there were usually a script per application on CRS.
The 'new-school' approach seems to be using one complex script that is modified and tweaked to fit the needs of the customer. This is commonly done by using constant XML lookups to check for variables, prompt paths etc. The benefit of this is that there is only one script and the admins can administer parts of the script using ASP pages to change the XML. For someone else to pick this script up and debug it can sometimes be difficult.
So, what is the consensus are you 'old-school' or 'new-school'?
Since im still in basic mode and i have almost no web building skills i prefer the old approach.
I am not to sure about new school or old school ways but i can tell you that using XML all over massive scripts is not a good idea. Your be ok if you have a few agents and maybe a couple of scripts but if you are deploying any thing of a reasonable size your going to have issues. The main issues that your hit are memory leaks.
Take a look at the document below. It gives UCCX recommnedations about script sizes and the use of xml.
The current script is not particularly large but it is heavily based on XML and supports several applications so according to the link you included im certain that rewriting to make it more understandable for me is the best option.
RE: "New School" vs. "Old School" scripting philosophies.
My own experience...
Overly complex "One script does it all" scripts are tough for the end user to both modify, and debug.
From a "customer support & satisfaction" standpoint, I prefer to supply a script/application that does what the customer needs, in the simplest form possible.
That way, when I'm off fishing, my CrackBerry is not blowing up with people looking for advice on how to find and resolve issues. They are able to figure out problems, and make additions/modifications to scripts/applications *themselves*.
Many a times needs are not simple to begin with and if they are over the time they out grow the simplicity
creating complex band aid solution to a good size problem. This will become a major head ache to support and keep it alive.
Having a good strategy, full understanding of long and short term goals, budget, growth and resources comes out the nature of your scripting and best practice. The best practice does not drive rather the business needs drive any practice.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...