- No changes to your code: you shouldn't have to comb through your code to remove or comment out your logging statements.
- Negligible performance impacts: your "productionized" code shouldn't suffer any performance impacts for having the logging system in place.
- Negligible page weight impacts: likewise, your productionized pages should incur a negligible page weight penalty for including the logging code.
- Easy troubleshooting in production: once you are in a production environment, you should be able to easily re-enable logging output, to troubleshoot in a pinch.
With JSLog you can leave your logging statements in, even in production code. Here's how to do it:
1. Quick and Easy: Disable JSLog site-wide via a configuration setting
Impact: the logger panel will no longer be visible, and you can leave all of your JSLog calls in your code. The calls become nullops, so the runtime penalty is negligible. However, your users will still be downloading the 6K jslog.js file.
Need to revisit your logging output? If you need to make the debugging panel visible on a page-by-page basis, you can include the string "enablejslog" in the url. Example: http://localhost/mypage.do?foo=bar&enablejslog. Including the string "enablejslog" overrides the "config_enabled=false," and you can see any JSLog output the page generates.
2. Production Grade: Replace the jslog.js file with a stub
Replacing the jslog.js file with a stub makes both the page weight and performance impacts of leaving your logging statements in your code negligable. Here's how:
A) rename jslog.js to jslog_real.js. The jslog_real.js file will continue to contain the full 6K JSLog implementation, but it will no longer be included in your pages because it has been renamed.
B) create a new jslog.js file with the following:
The part starting with "if" means you can enalble logging on a page-by-page basis, for example: http://clientsite/page.php?foo=bar&enablejslog, and the stub will dynamically include the real JSLog object, so you can see JSLog output in the JSLog panel as usual. You can leave out the part starting with "if" if you don't need/want that cabability, or just want to save a few extra bytes.
This really gives you the best of all worlds: 1) the ability to leave your logging statements in your code, even as you deploy it to a client; 2) negligible performance impact of leaving the logging statements in; 3) negligible impact on page weight for everyday use; 4) immediate access to the JSLog output if you need to troubleshoot in the production environment.
JSLog can be part of your strategy as your Ajax code matures from development to production. Even when your code is ready to be fully productionized, it's often helpful to leave your logging code in, for two reasons: 1) it's a pain to remove it, and you can inadvertently introduce errors in your code just be remove logging statements; 2) there is no such thing as code that is completely "done!" At some point you will need to go into that code and make changes, and go through another round of debugging/testing/deployment -- and when you do, it will help to have the logging and debugging statements there.
The configuration setting to turn of JSLog output (by making all JSLog calls null ops) is one easy way to productionize your code without having to remove your logging statements. If pageweight is a concern, you can replace the jslog.js file with a 133-byte stub, which can easily be swapped out if you need to troubleshoot your code. Furthermore, with one additional line of code in the stub file, you can provide the ability to dynamically include the JSLog functionality by typing "enablejslog" in any url. You can use this to help troubleshoot code even after it has been deployed in a production environment.