The lack of a CPTableView is why I ultimately decided not to use Cappuccino for a back-end project I was working on recently; looks like the wait was worth it -- what a beautiful implementation.
Huge congrats to 280North for shipping this. The CommonJS and Jake stuff is awesome. It's also good to see the tableview and outlineview stuff make it back into the main branch.
We're still shipping updates to the Atlas beta. Not quite sure when a final release will be ready. In any case, we're continuing to write code like mad men.
Slightly off topic, but can you guys please add back the nice source list to Atlas like you had in the original intro/example video? It would be perfect for a project I'm working on.
I'm really, really intrigued by the base-64 assets with an MHTML fallback technique for reducing HTTP requests. What is the best way to do this without using Cappuccino?
It's a bit easier in a managed framework like Cappuccino, since we have the opportunity to swap URLs before using them. Typically you ask a "bundle" (CFBundle/CPBundle) for a resource's URL, and it will give you back a data URI or MHTML URL for that resource if it has one and the browser supports it, otherwise it will give you the individual image's URL.
In JavaScript you would need a similar layer of indirection. I don't know how you would do it for CSS (presumably inlining them directly in the CSS?)
jashkenas mentioned he was using the data URI / MHTML technique in Jammit for Rails (http://documentcloud.github.com/jammit/) but I haven't looked into the details.
Also note we do runtime detection of support for data URIs or MHTML. There's a version of IE (IE7 on Vista, I think) which we have to fallback to individual images for.
* You define your CSS asset packages as you see fit, using an ordered list of directory globs that gets expanded into a list of unique stylesheet names. (Same idea for JS packages).
* Minified, compressed versions are generated, using either the YUI Compressor (for CSS or JS) or Google Closure Compiler (for JS only), in both MHTML and Data-URI variants.
* Helpers are provided using conditional comments to serve the appropriate stylesheets to the appropriate browsers.
* Finally, packages are "gzip --best"'d, so that you can have your webserver serve them entirely statically.
* If you've set it up properly, you can have a single HTTP request that contains all your stylesheets for the page, as well as all of your embedded images and web-fonts.
Just for kicks, here's an example with a stylesheet that references 100 small images. There's a link on the page to the packaged version. Try the difference over wifi.
If you're looking to implement MHTML yourself, be careful about whitespace. Internet Explorer will cheerfully ignore MHTML assets that contain Unix-style newlines.
You have to be a little careful here, as certain versions of IE won't render MHTML assets the second time they area loaded, but again only under certain circumstances.
In Cappuccino, in addition to building in all the known workarounds (serving mhtml files with content type of text/plain, adding cache busting parameters if needed), we actually perform a runtime check of the supported feature before we use it. So, we try to load a single 1px dataURL image, and if that fails we try to load a known 1px MHTML image, and if that fails we fallback to the original image resources.
we already have ext, qooxdoo, yui, gwt, etc. how does cappuccino differ from those existing and well-established projects? eg qooxdoo does implement a decent oo layer on top of standard javascipt, and also supports ie6. what are the advantages of cappuccino?
