Getting Set Up for Web Development with Cappuccino
Programming for the browser is significantly different from other programming environments like a desktop OS, or even server side code. Cappuccino is largely aimed at minimizing these differences, but to be most productive you'll need to be familiar with the right set of tools. This tutorial is aimed at identifying the most useful tools for developing Cappuccino applications. If you're already ready to start programming your first Cappuccino application, try this tutorial.
Browsers
The browser is the most important part of the development cycle. Cappuccino apps target the browser just like Cocoa apps target Mac OS X. Choosing the right browser for your development cycle is a crucial step in the process.
There's no one right answer to the question of which browser you should be using. There are three obvious contenders: Internet Explorer, Firefox, and Safari.
Firefox
Many web developers today choose to go with the latest version of Firefox. One of the biggest motivations for the choice is the availability of the Firebug extension. Firebug gives you plenty of great features for debugging your applications like stack traces on exceptions, a JavaScript profiler for finding performance hot spots, and a monitor for all your http traffic, including XMLHTTPRequests. If you're going to use Firefox, Firebug is really an essential add-on to have.
Of all the browsers, Firefox also gives the most comprehensive error logs. In particular, parse errors tend to include specific issues and have helpful hints about where in the code to look for the problem. Other exceptions also usually report better errors than the other browsers. Even if you choose to use another browser for development, having a copy of Firefox around is good practice for solving hard to find problems.
Safari
Safari is a somewhat less popular choice, especially because the shipping version of Safari has a somewhat poor set of developer tools. Fortunately that problem is being solved, and the latest nightlies have great additions to the Safari Web Inspector, including a debugger, profiler, and http monitor. To access the inspector, you'll need to check the "Show Develop menu in the menu bar" checkbox in the Advanced section of the preferences.
Safari does has a few advantages over Firefox. First, it's a faster browser, especially at JavaScript. Although both browsers are fast, when you're in the rapid development cycle of programming, refreshing, and testing your changes, the extra speed boost can be useful. Second, and perhaps more importantly, Safari has a slightly different security model than Firefox when it comes to XMLHTTPRequests and the same origin policy.
In Safari, files running locally (i.e. file:///MyFolder/MyApplication/index.html) are allowed to access requests from any origin. This was designed so that Dashboard widgets could access external sites, but it's especially useful for application development. You can leave a working copy of your application on a separate webserver or development box, and use it as your backend for local development, without worrying about the same origin policy.
Internet Explorer
Cappuccino works great in IE, and you should test your application in IE as often as possible. It is not recommended as a development environment though. IE's JavaScript interpreter is the slowest of the modern browsers, and it has some of the worst debugging tools.
That being said, since you should and will need to use IE from time to time, it's useful to know that there are tools out there to make your experience better. One is Companion.js, a tool that provides an interactive DOM inspector and JS console. Another is the MS Script Debugger, which is required for parts of Companion.js to function properly, but is useful in its own right.
Editors
You can use whatever code editor you're familiar and comfortable with. Preferably you'll want one that at least supports JavaScript as a native language. Since Objective-J is very close to JavaScript, it makes the best choice for an editing mode if native Objective-J support is unavailable.
Existing Editor Add-Ons
- SubEthaEdit
- Coda for Mac OS X has built in support for Objective-J syntax highlighting.
- TextMate - with updates from Vijay Kiran
- VIM - thanks to Shawn MacIntyre
- xCode - thanks to Raphael Bartolome
If you use another text editor, and have written or would like to write an add-on for it to support Objective-J, we strongly encourage it and will list it here. Get in touch with us at developers@280north.com.
Logging
Logging is an important part of the development process, especially when a debugger isn't available. Over the years, people have adapted various methods of logging in web applications. All of those methods will still work, and you should use them if you have a favorite.
Cappuccino does come with its own built in logger. CPLog is modelled after Apache's log4j, and is easy to use. Anywhere in your code, you can simply call CPLog("a message") to print that log. You can also use CPLog.error("an error"), CPLog.debug("a debug message"), and others. Logs are displayed in a popup log window, but they're turned off by default. To enable them, you can append #debug to the end of your URL. So, if I'm developing at:
http://localhost/MyApp/
I would instead go to:
http://localhost/MyApp/#debug
to enable the debug console. The console can also be enabled by calling CPLogRegister(CPLogPopup) in your code. More documentation on CPLog will be made available soon.
Compiler
For those developers used to languages like Java, C++, or Objective-C, where the compiler is readily available to show you syntax and type errors, changing to Objective-J and JavaScript can be confusing at first. You will not be able to rely on a compiler to find these kinds of problems for you. Most of them will be found by the browser when you first load your application, and you'll find those errors buried in the JavaScript console of your respective browser. It's in the Debug menu in Safari, and in the Tools menu of Firefox (if you have Firebug installed, errors will appear in Firebug instead).
It's important to run your code often to make sure it still works. You don't want to end up with 300 new lines of code and no clue where the error has occured. This is somewhat exacerbated by the fact that Objective-J has difficulty reporting the actual line number of errors. So remember to run your code often, and make use of the error console and the other tools you have available when you encounter trouble.
Additional Info
I'm sure we're missing important information in this guide. If you have suggestions, send them to developers@280north.com. If you have questions that haven't been answered here, you should try the mailing list or IRC channel.
