Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- Technology and Support
- DevNet Hub
- DevNet Collaboration
- Collaboration Knowledge Base
- CVP Developer Best Practices
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
408
Views
0
Helpful
0
Comments
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 01-25-2014 10:26 AM
This document was generated from CDN thread
Created by: Jeff Russell on 17-01-2013 09:13:15 AM
I am currently running CVP Developer 8.5 in a test lab environment. I am attempting to document a "Best Practices" list for development/testing/deployment of scripts.
Any suggestions and/or reference material to get me started would be greatly appreciated.
Thanks!
Subject: RE: CVP Developer Best Practices
Replied by: Asher Schweigart on 22-01-2013 02:05:01 PM
#1. Version control your files. Preferably, this should also include a backup of the files, in case you muck up your CS box.
Personally, I use git for version control, but whatever you prefer, just get some sort of VCS setup.
#2. Create, and stick to, a naming scheme for elements. You should be able to figure out exactly what type an element is without clicking on it, just based on the name.
examples:
Audio element to play hours.wav - "playHours"
Form element for main menu - "formMainMenu"
A side note to this; your elements should have descriptive names. Avoid using numbers in elements (Audio_01, Audio_02), unless it is actually relevant.
#3. Create a test script that has a test number pointing to it. This script can then be used for testing new custom elements, or for small branches of code that you want to test on a live call instead of the debugger.
#4. Each of your scripts' first page should be a doc page, listing things like creator, creation date, modifier, modification date, summary of what the script does, etc. This page should not have the call start element. That should be on the second page.
Also, name your pages. Page1, page2, etc, does not help people read a script later!
#5. If you have strings in your script, such as a phone number to forward to for help, or an email address that you are sending error messages to, set those as session variables in the first few elements of the script, so you can change them easily if needed.
#6. Use custom elements, not the generic action element, when you are using custom java code. The few extra steps it takes to make custom java a custom element is not that bad, and will make your scripts easier to read.
#7. Do not make a single page in your script larger than you can see at once on the standard size monitor for your script developers. This isn't always possible to follow, and in some cases may seem hard to follow, but if you don't have to scroll around on a page to read a script, it is much easier. It will mean for complicated scripts you might have 10+ pages, but in my opinion, that is far easier to navigate than 2-3 pages that you can only see 25% of at a time. (Yes, CS does have zoom controls, but just zooming one level out makes the page almost impossible to read.)
#8. Unless absolutely necessary, do not cross lines connecting elements. That makes a script difficult to read.
#9. If you find yourself doing something with 4-5 elements multiple times, and the same action could be done with one custom element, then write a custom element. For example, I had multiple cases where I needed to set a variable to something based on the value of the DNIS. To do this, I had to have an if node with multiple branches each pointing to a different App Mod node that set a variable to a different value. To make this easier, I created a switch node that does the same thing, but in one single element, and with no app mod element.
#10. (#1 in importance!) Comment, comment, comment. If an element's name isn't enough to indicate what that element is there for, it should have a comment element near it.
Subject: RE: CVP Developer Best Practices
Replied by: Jeff Russell on 22-01-2013 02:32:53 PM
Thanks Asher,
This is a great start!
Jeff
Subject: RE: New Message from Asher Schweigart in Customer Voice Portal (CVP) - Trai
Replied by: Hemal Mehta on 22-01-2013 02:59:09 PM
Use custom elements, not the generic action element, when you are using custom java code. The few extra steps it takes to make custom java a custom element is not that bad, and will make your scripts easier to read.
I do not necessarily agree with this. It’s a case by case situation and depends on what your needs are. There are some places where it makes sense. Making every java class a custom element is a overkill. You can always add comments, for clarity. Also when I port or upgrade between versions, the code can be literally imported into the new studio and made to work with minimum effort.
Hemal
From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, January 22, 2013 2:05 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Asher Schweigart in Customer Voice Portal (CVP) - Training Forum: RE: CVP Developer Best Practices
Asher Schweigart has created a new message in the forum "Training Forum": -------------------------------------------------------------- #1. Version control your files. Preferably, this should also include a backup of the files, in case you muck up your CS box.
Personally, I use git for version control, but whatever you prefer, just get some sort of VCS setup.
#2. Create, and stick to, a naming scheme for elements. You should be able to figure out exactly what type an element is without clicking on it, just based on the name.
examples:
Audio element to play hours.wav - "playHours"
Form element for main menu - "formMainMenu"
A side note to this; your elements should have descriptive names. Avoid using numbers in elements (Audio_01, Audio_02), unless it is actually relevant.
#3. Create a test script that has a test number pointing to it. This script can then be used for testing new custom elements, or for small branches of code that you want to test on a live call instead of the debugger.
#4. Each of your scripts' first page should be a doc page, listing things like creator, creation date, modifier, modification date, summary of what the script does, etc.
#5. If you have strings in your script, such as a phone number to forward to for help, or an email address that you are sending error messages to, set those as session variables in the first few elements of the script, so you can change them easily if needed.
#6. Use custom elements, not the generic action element, when you are using custom java code. The few extra steps it takes to make custom java a custom element is not that bad, and will make your scripts easier to read.
#7. Do not make a single page in your script larger than you can see at once on the standard size monitor for your script developers. This isn't always possible to follow, and in some cases may seem hard to follow, but if you don't have to scroll around on a page to read a script, it is much easier. It will mean for complicated scripts you might have 10+ pages, but in my opinion, that is far easier to navigate than 2-3 pages that you can only see 25% of at a time. (Yes, CS does have zoom controls, but just zooming one level out makes the page almost impossible to read.)
#8. Unless absolutely necessary, do not cross lines connecting elements. That makes a script difficult to read.
#9. If you find yourself doing something with 4-5 elements multiple times, and the same action could be done with one custom element, then write a custom element. For example, I had multiple cases where I needed to set a variable to something based on the value of the DNIS. To do this, I had to have an if node with multiple branches each pointing to a different App Mod node that set a variable to a different value. To make this easier, I created a switch node that does the same thing, but in one single element, and with no app mod element.
#10. (#1 in importance!) Comment, comment, comment. If an element's name isn't enough to indicate what that element is there for, it should have a comment element near it.
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/11003886 or simply reply to this email.
Subject: Re: New Message from Hemal Mehta in Customer Voice Portal (CVP) - Training
Replied by: Janine Graves on 22-01-2013 05:35:12 PM
Yes, Hemal, but customers who come into class despise standard Action and Decision elements. A year after they get the code, all the documentation is lost and they have no idea what the elements are doing. By turning them into elements, one can add a useful description of the variables the element is getting and setting. Even if you don't add a Settings tab, turning them into custom elements makes the customer sooooo much happier! -- Janine Graves
Subject: RE: New Message from Janine Graves in Customer Voice Portal (CVP) - Trainin
Replied by: Hemal Mehta on 22-01-2013 09:01:09 PM
Janine, I agree with some of it and it depends from customer to customer. It depends on how well your java code is wriitten and if you have documented it well. You can easily generate java doc anytime. My code is all documented and it cannot be lost. Also comments are added fo each action element. You can add the same documentation in your java class itself. Again there are several ways to do this. My point is that if I have 40 different java classes, I would not like to create 40 different custom elements.
Hemal
________________________________________
From: Cisco Developer Community Forums [cdicuser@developer.cisco.com]
Sent: Tuesday, January 22, 2013 5:35 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Janine Graves in Customer Voice Portal (CVP) - Training Forum: Re: New Message from Hemal Mehta in Customer Voice Portal (CVP) - Training
Janine Graves has created a new message in the forum "Training Forum": -------------------------------------------------------------- Yes, Hemal, but customers who come into class despise standard Action and Decision elements. A year after they get the code, all the documentation is lost and they have no idea what the elements are doing. By turning them into elements, one can add a useful description of the variables the element is getting and setting. Even if you don't add a Settings tab, turning them into custom elements makes the customer sooooo much happier! -- Janine Graves
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/11009605 or simply reply to this email.
Created by: Jeff Russell on 17-01-2013 09:13:15 AM
I am currently running CVP Developer 8.5 in a test lab environment. I am attempting to document a "Best Practices" list for development/testing/deployment of scripts.
Any suggestions and/or reference material to get me started would be greatly appreciated.
Thanks!
Subject: RE: CVP Developer Best Practices
Replied by: Asher Schweigart on 22-01-2013 02:05:01 PM
#1. Version control your files. Preferably, this should also include a backup of the files, in case you muck up your CS box.
Personally, I use git for version control, but whatever you prefer, just get some sort of VCS setup.
#2. Create, and stick to, a naming scheme for elements. You should be able to figure out exactly what type an element is without clicking on it, just based on the name.
examples:
Audio element to play hours.wav - "playHours"
Form element for main menu - "formMainMenu"
A side note to this; your elements should have descriptive names. Avoid using numbers in elements (Audio_01, Audio_02), unless it is actually relevant.
#3. Create a test script that has a test number pointing to it. This script can then be used for testing new custom elements, or for small branches of code that you want to test on a live call instead of the debugger.
#4. Each of your scripts' first page should be a doc page, listing things like creator, creation date, modifier, modification date, summary of what the script does, etc. This page should not have the call start element. That should be on the second page.
Also, name your pages. Page1, page2, etc, does not help people read a script later!
#5. If you have strings in your script, such as a phone number to forward to for help, or an email address that you are sending error messages to, set those as session variables in the first few elements of the script, so you can change them easily if needed.
#6. Use custom elements, not the generic action element, when you are using custom java code. The few extra steps it takes to make custom java a custom element is not that bad, and will make your scripts easier to read.
#7. Do not make a single page in your script larger than you can see at once on the standard size monitor for your script developers. This isn't always possible to follow, and in some cases may seem hard to follow, but if you don't have to scroll around on a page to read a script, it is much easier. It will mean for complicated scripts you might have 10+ pages, but in my opinion, that is far easier to navigate than 2-3 pages that you can only see 25% of at a time. (Yes, CS does have zoom controls, but just zooming one level out makes the page almost impossible to read.)
#8. Unless absolutely necessary, do not cross lines connecting elements. That makes a script difficult to read.
#9. If you find yourself doing something with 4-5 elements multiple times, and the same action could be done with one custom element, then write a custom element. For example, I had multiple cases where I needed to set a variable to something based on the value of the DNIS. To do this, I had to have an if node with multiple branches each pointing to a different App Mod node that set a variable to a different value. To make this easier, I created a switch node that does the same thing, but in one single element, and with no app mod element.
#10. (#1 in importance!) Comment, comment, comment. If an element's name isn't enough to indicate what that element is there for, it should have a comment element near it.
Subject: RE: CVP Developer Best Practices
Replied by: Jeff Russell on 22-01-2013 02:32:53 PM
Thanks Asher,
This is a great start!
Jeff
Subject: RE: New Message from Asher Schweigart in Customer Voice Portal (CVP) - Trai
Replied by: Hemal Mehta on 22-01-2013 02:59:09 PM
Use custom elements, not the generic action element, when you are using custom java code. The few extra steps it takes to make custom java a custom element is not that bad, and will make your scripts easier to read.
I do not necessarily agree with this. It’s a case by case situation and depends on what your needs are. There are some places where it makes sense. Making every java class a custom element is a overkill. You can always add comments, for clarity. Also when I port or upgrade between versions, the code can be literally imported into the new studio and made to work with minimum effort.
Hemal
From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, January 22, 2013 2:05 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Asher Schweigart in Customer Voice Portal (CVP) - Training Forum: RE: CVP Developer Best Practices
Asher Schweigart has created a new message in the forum "Training Forum": -------------------------------------------------------------- #1. Version control your files. Preferably, this should also include a backup of the files, in case you muck up your CS box.
Personally, I use git for version control, but whatever you prefer, just get some sort of VCS setup.
#2. Create, and stick to, a naming scheme for elements. You should be able to figure out exactly what type an element is without clicking on it, just based on the name.
examples:
Audio element to play hours.wav - "playHours"
Form element for main menu - "formMainMenu"
A side note to this; your elements should have descriptive names. Avoid using numbers in elements (Audio_01, Audio_02), unless it is actually relevant.
#3. Create a test script that has a test number pointing to it. This script can then be used for testing new custom elements, or for small branches of code that you want to test on a live call instead of the debugger.
#4. Each of your scripts' first page should be a doc page, listing things like creator, creation date, modifier, modification date, summary of what the script does, etc.
#5. If you have strings in your script, such as a phone number to forward to for help, or an email address that you are sending error messages to, set those as session variables in the first few elements of the script, so you can change them easily if needed.
#6. Use custom elements, not the generic action element, when you are using custom java code. The few extra steps it takes to make custom java a custom element is not that bad, and will make your scripts easier to read.
#7. Do not make a single page in your script larger than you can see at once on the standard size monitor for your script developers. This isn't always possible to follow, and in some cases may seem hard to follow, but if you don't have to scroll around on a page to read a script, it is much easier. It will mean for complicated scripts you might have 10+ pages, but in my opinion, that is far easier to navigate than 2-3 pages that you can only see 25% of at a time. (Yes, CS does have zoom controls, but just zooming one level out makes the page almost impossible to read.)
#8. Unless absolutely necessary, do not cross lines connecting elements. That makes a script difficult to read.
#9. If you find yourself doing something with 4-5 elements multiple times, and the same action could be done with one custom element, then write a custom element. For example, I had multiple cases where I needed to set a variable to something based on the value of the DNIS. To do this, I had to have an if node with multiple branches each pointing to a different App Mod node that set a variable to a different value. To make this easier, I created a switch node that does the same thing, but in one single element, and with no app mod element.
#10. (#1 in importance!) Comment, comment, comment. If an element's name isn't enough to indicate what that element is there for, it should have a comment element near it.
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/11003886 or simply reply to this email.
Subject: Re: New Message from Hemal Mehta in Customer Voice Portal (CVP) - Training
Replied by: Janine Graves on 22-01-2013 05:35:12 PM
Yes, Hemal, but customers who come into class despise standard Action and Decision elements. A year after they get the code, all the documentation is lost and they have no idea what the elements are doing. By turning them into elements, one can add a useful description of the variables the element is getting and setting. Even if you don't add a Settings tab, turning them into custom elements makes the customer sooooo much happier! -- Janine Graves
Subject: RE: New Message from Janine Graves in Customer Voice Portal (CVP) - Trainin
Replied by: Hemal Mehta on 22-01-2013 09:01:09 PM
Janine, I agree with some of it and it depends from customer to customer. It depends on how well your java code is wriitten and if you have documented it well. You can easily generate java doc anytime. My code is all documented and it cannot be lost. Also comments are added fo each action element. You can add the same documentation in your java class itself. Again there are several ways to do this. My point is that if I have 40 different java classes, I would not like to create 40 different custom elements.
Hemal
________________________________________
From: Cisco Developer Community Forums [cdicuser@developer.cisco.com]
Sent: Tuesday, January 22, 2013 5:35 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Janine Graves in Customer Voice Portal (CVP) - Training Forum: Re: New Message from Hemal Mehta in Customer Voice Portal (CVP) - Training
Janine Graves has created a new message in the forum "Training Forum": -------------------------------------------------------------- Yes, Hemal, but customers who come into class despise standard Action and Decision elements. A year after they get the code, all the documentation is lost and they have no idea what the elements are doing. By turning them into elements, one can add a useful description of the variables the element is getting and setting. Even if you don't add a Settings tab, turning them into custom elements makes the customer sooooo much happier! -- Janine Graves
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/11009605 or simply reply to this email.
Labels:
Getting Started
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
Customers Also Viewed These Support Documents