- Use the transport mechanism to send debug information. For example, if you’re sending back an array of data, add a new element (or several), and put in the SQL query so you can see exactly what’s being executed.
- Store the returned data in global variables on the client side and use Firebug to examine them. console.debug and alert are helpful, too.
- Use var_dump and echo if you get frustrated. They’ll probably throw an error on the client side, but you’ll get to see what you want to.
- Use var_export($variable,true) if you want to do a var_dump to a string or to a file. file_put_contents(’/tmp/file’,$data,FILE_APPEND); is a great way to monitor script execution. Open a new SSH window and use tail -f /tmp/file to see it.
- Cut and paste output into Notepad so you can easily verify it. Often you need several chunks of text and data to truly understand what is happening and why.
- Develop complex pieces in a standalone environment. This is good for assembling arrays of data out of complex SQL queries. Simplifying the task so you can focus on the difficult parts will speed development.
- Watch out for extra commas in object assignments. IE will crash.
- If you have Visual Studio, use it. It can save you a tremendous amount of time when debugging under IE.
- Test for the presence of variables, objects, and attributes before using them. It isn’t really right, but you can use if (variable_exists) to see if the variable has been set up. A better solution is to initialize everything, or to use if (typeof variable != ‘undefined’).
- To remove something from a page, use style="display:none". It works, it’s simple, and it’s very low risk. If anyone is playing with your code, they’ll find it, but it shouldn’t be an issue unless it had security issues, or restricted content.
- Add a debug setting to your code that allows you to receive more information when errors occur. You can disable it for the production release.
Notes on using dojox Charting.
- Read the documention at the link above.
- Assemble the page as AJAX from the beginning. Don’t bother building an HTML version first, the number of requests required for charting is large enough that these pages should be AJAX pages. Zend Framework’s Dojo Data (http://framework.zend.com/manual/en/zend.dojo.data.html) component is an excellent way to encode the data for transport. Zend Framework can be used as a library.
- Consider using a pulldown to allow the viewer to select the theme used. This is nice for appearance and fun, but may also be valuable for people that have difficulty distinguising colors. A simple loop that lists the available themes, uses a dojo.require to fetch the code, and then applies them to the charts and legends with chart.SetTheme, chart.render, and legend.refresh is a nice feature.
- Think carefully about what charts you’d like to use. This link
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/charting/tests/test_chart2d.html has great sample code. Take the time to look at the charts available. Moving up a level or two in the directory tree yields additional, valuable code.
- Use updateSeries if possible to redraw charts, if necessary, use destroy, then recreate them.
- Offer good explanatory text to help people interpret the displays.
- Write the queries carefully, it’s often faster to query, then use arithmetic to find out other portions of the data. Don’t forget to fill in gaps of missing data for series that illustrate usage or events across time spans.
- Be sure to sanitize and validate the data. Always.
Sometimes, code doesn’t do what it is supposed to, or what you expect. This is particularly common with open source code you didn’t write.
You can’t change the basic code architecture or data structures.
Take the time to look for examples in the code, so you don’t have to figure it all out from scratch. Usually, modifications to open source code involve code similar to that which is already in there, for example reassigning values.
If you have an AJAX application that won’t load, and the error message is difficult to match up with the code, or not descriptive, one of the best things to check is the objects for trailing commas.
The code below will run fine in FF, but will not load in IE, because of the trailing comma after the second object in the array.
Brute force debugging with alert statements may be helpful.
Each step ends with place in version control, submit for review, evaluate review responses and apply them as appropriate..
- Define the page architecture, common page elements first. These must be stable before beginning.
- Build page level XHTML/CSS for all pages, target browser FireFox, with only enough back end code to deliver the pages. Use static server-side content to populate dynamic controls/queries for illustration. Create data in the database to support it. Validate the XHTML/CSS as well as possible (some libraries have proprietary attributes).
- If common components are identified in the previous step, they should be constructed reusable/shared components. For example, a file upload or search results dialog box will probably be used in more than one place. Both client and server-side code should address this to avoid duplicate code.
- Tune colors.
- Define and implement client-side functionality, allowing content to be delivered through AJAX, navigation, any dynamic operations.
- Implement client-side validation.
- Extend pages to run under any other browsers you will be supporting. Clearly indicate limitations, such as will function but may not display well. Provide notification for users of unsupported browsers.
- Integrate and implement server-side validation. It should be identical to client-side validation, with addition considerations for security.
- Implement page level functionality.
- Test, test, test.