MapGuide Application Development tips

Sometimes on the mapguide-users mailing list, we get questions that make me scratch my head sometimes. These are questions that can answer themselves with the use and knowlege of the right tools and configuration settings.

So giving the benefit of the doubt regarding programming ability, and simply assuming the case of "not knowing what's out there", here's the tools and configuration settings that I always use when developing MapGuide applications, which should greatly assist and simplify the process of developing and debugging MapGuide applications. Experienced web developers can probably tune out because you should already know these tools :)

1. Firebug

If you haven't heard of firebug or haven't used it before, stop reading this post and download it now. DO IT!

If firebug didn't exist, I probably wouldn't be taking Web Development as seriously (hell, I probably wouldn't do web development full stop!). If you do any development on the MapGuide Platform (or web development in general), you will have to write some javascript and firebug provides top-class debugging facilities.

But it doesn't just do javascript, it also does:

• CSS/DOM debugging
• HTTP request tracing / performance monitoring. (you can see all the requests that Fusion/AJAX viewer is making to your MapGuide Web Tier)
  
• Lots more!
  

It is the complete web development package! Of course, you should already know that (and I shouldn't even have to be writing this post!)

2. Mozilla Firefox

Besides the fact that this is needed for firebug, Firefox is the epitomy of the modern web browser, and has lots of healthy competition from Google Chrome and other WebKit-based bretheren to help keep moving the web forward ... Unlike that browser from Redmond^!

But even still, the Firefox + Firebug combination provides a solid foundation for your design ensuring that the time spent in Internet Explorer is kept to a minimum*

My web development workflow is simply:

1. Design and develop and test in Firefox / Firebug. This design will 99.9% work in all modern browsers.
   
2. Contort and bastardise this design (hopefully not too much) to make it work in Internet Explorer
3. Re-test against Firefox / Firebug to ensure no breakages.

Simply put, the Firefox + Firebug combination significantly reduces the time spent in the 2nd step of this workflow. The amount of pain and suffering (and the amount of swearing directed at Redmond) would be kept to a minimum.

3. Baretail + MapGuide log files

Believe it or not, MapGuide actually logs lots of information when its running (under default server configuration settings). If a viewer has made a request to the MapGuide Server, it is logged. If MapGuide throws an error, it is logged. If something has made the MapGuide Server fall over, chances are it is logged. Simply put, the logging facilities built into MapGuide provides you with a lot of information to work with. When things go south in your MapGuide application, the log files should almost always be the first port of call.

Baretail is a windows utility that is effectively the windows equivalent to the unix tail utility, showing you the latest entries in error.log and access.log (and any other log file) as they are written by the MapGuide Server. It is an invaluable resource to assist in debugging and problem diagnosis. Does your MapGuide application code not work? Try running it again while observing the mapguide logs under baretail. They might tell you something.

4. Set display_errors = On in php.ini

The PHP that is bundled with MapGuide uses production-level settings. This means any warnings or errors (like unhandled MapGuide exceptions) in any PHP code you may be running are silently swept under the carpet most of the time. Setting the display_errors setting to On in php.ini will reveal and display these errors. If PHP is your development environment, this should be the first thing you do on a fresh development install of MapGuide.

5. JavaScript lint

Sometimes I wish JavaScript was a compiled language. That way the theoretical javascript compiler can report to me all the syntax errors it finds in my javascript source code immediately instead of me having to wait until runtime to get a nasty surprise!

Well JavaScript will never become a compiled language, but we do have JavaScript Lint which is the closest thing we will ever get to a "compiler". Usage is simple, run the jsl.exe executable on your javascript source and watch it report any javascript syntax errors with matching line numbers!

Knowing these tools and configuration settings have made my web development life simpler, I hope this post makes your's simpler too!

^ Generally speaking, where IE gets it completely wrong is in two areas: 1) Certain parts of the DOM API and 2) Flagrant disregard or misinterpretation of certain CSS rules (most infamously, the box model bug). But it's 2011, these are known problems solved by almost every web framework out there, which you should be using already! Which is why I said that the Firefox + Firebug combination takes you 90% there.

* I think if all of us web developers charged a mandatory "IE tax" on our web development work, it would make some of these regressive organisations think twice about holding us (and the modern web) back by still mandating Internet Explorer 6 as the "standard web browser". Microsoft got the message, why won't you!? To be fair, none of the clients I have worked with in my career thus far fall under this category, but the fact that there are still such organisations out there makes baby Jesus cry! At least IE9 is a half-modern web browser, and if Microsoft is serious about its vision of application development for Windows 8, they have no choice but to make IE10 an actual functional modern web browser!