Using XML Technologies For Enhancing Log Files
ConclusionYou now have a very powerful new way of using log files in your software and one that was achieved using relatively simple technologies that are both easily and freely available. You also have a lot of flexibility to customize it to your own personal (or team's) needs, making it as complicated and dynamic as you see fit. This article has touched on four main technologies XML, XSLT, HTML and JavaScript but none of them have been used to their full potential, or to an overly advanced level. It is interesting to note how a relatively simple use of multiple technologies combines together to generate one powerful solution something that is very prevalent in commercial software these days. As mentioned, there is scope to take this material further a line was drawn for this article so as to stop it from becoming too complex, but there are a few extensions worth pointing out that you may well wish to take a closer look at. The most obvious would be to add more xsl:params to the XSLT transform file such as limiting the range of outputted LogEvents to within a range of ID numbers or time indices. If you customize the format of the XML output then it's quite likely that you'll want to add extra xsl:params to handle filtering of these properties. Just be careful, ideally at the design stage, of combinatorial explosion with only three parameters the current XSLT implementation can appear quite cluttered. It would be very possible to dynamically allow the user to specify both the source XML and XSLT files meaning that the JavaScript/HTML could become a tool that rarely need be left by the user; one where a number of log files could be viewed without having to load up distinctly different HTML files. The ability to specify different XSLT files allows the output to be customized according to whatever form the current user wishes both on an aesthetic front and on a functional tone (e.g. A high-contrast/large-font output for those with visual impairments). Another possibility is to package everything up as a dedicated tool most browsers have re-usable components (e.g. the MSIE ActiveX control) that can be embedded into applications. This can go some way to avoiding any support/configuration issues by making sure that the necessary components are all packaged together in a self contained distributable form. The other direction could be to make this technology appear in a more "web like" context having the log files stored on (or written to) a web server, and the viewer being just another web page that can be loaded up on the client machine. 'Cookies' could be incorporated into this so as to remember preferences such as default search or preferred XSLT transform. This possibility could help alleviate many of the browser issues encountered as the server can be used to process and transform the XML file to be displayed. In closing, I hope you found this article interesting and hopefully you can actually make some use of the ideas presented here. If you have any questions/comments regarding this article you can contact us via the GameDev.net forums by sending a 'Private Message' to Jack [24] or Oli [25]. Even if you don't have any questions, we'd always be interested in hearing if people have used the technology in their own projects You can also download all of the relevant files as an archive from here [26]. CreditsThe credits for this article are as follows. I, Jack, am the author of this article, with Oli providing the technical knowledge and information that led to the conception of this idea. Thanks are also due to Degra, Agony and Etnu for their contribution to the original thread. References[1] http://www.gamedev.net/community/forums/topic.asp?topic_id=299160
|
|