60,000 Lines of JavaScript... Wow. This post on the wdf-dom mailing list, which covers both large projects and large issues with JavaScript/DOM development, is fascinating to me. I've been noticing a growing number of powerful JavaScript / DOM browser based applications lately, from GMail, which includes a lot of in-page data updates outside of the full-page refresh cycle, to Kupu, which is a very powerful WYSIWYG style editor that effectively recreates WordPad or Netscape Composer inside of a web page. I've thought, recently, of getting back into this world. But usually, it makes me scream and cry. I have never had positive experiences with JavaScript, documentation, debugging, etc. This post, found via Tres Seaver, indicates that there are some really powerful and large scale projects being done with JavaScript and DOM. It also indicates that there are still some pretty big issues involved with undertaking such development.
On a related note, Nevow includes an interesting feature called LivePage:
LivePage was a Woven technology which allowed programmers to receive server-side notification of client-side JavaScript events, and to send JavaScript to the client in response to a server-side event. New for Nevow 0.3, LivePage has been updated to support Mozilla, Firefox, IE6 Win, and Safari.It's not just dynamic JavaScript rendering, it's dynamic transmission of JavaScript code to a page based on a server side event. I would like to imagine that this could even include sending messages to particular users when certain events happen and having those messages show up as JavaScript alert boxes, and having it all occur outside of the traditional web page refresh model.
Today, I started work on bridging two systems together. Both were primarily written by me, but to serve different ends, and both are built on Zope 2. One is an old e-commerce system that has recently undergone some radical improvements that have given it its own basic component architecture. The e-commerce system uses an RDBMS for its data store, and was recently converted to the table gateway model not much different than I documented here in May 2003. The other system is a lightweight and flexible content management system built around the notion of compound documents. Its descended from a few older projects, and the latest incarnation (the most solid one) has its own component architecture based on configurable policies held in policy managers. Policies dictate extended behavior for both resources (documents) and collections (folders), and works with regular Zope 2 folders just by adding a collection policy manager to that folder. The content management system is ZODB based, storing its data as regular objects in Zope's object database.
While the e-commerce system has its own sort of content management for dealing with images and text to associate with products and categories, it had no real way of letting a customer use the administration user interface to add, edit, or otherwise maintain other pages on the system. Even for those of us who work on the system, having to get in and edit a basic page like a privacy statement was sometimes more of a pain than it was worth. The page was just another page template in the system, and it was a minor annoyance mentally separating that content from the templates used to render the store's data.
Since a strong benefit of the component based stylings of each system is that customer specific enhancements can occur in separate Zope Products (a Zope unit of deployment, usually of pieces that fit together to make an application), I decided that it should be possible to make a product that bridged the two, effectively adapting the data model of the content system to the Page Controller based system used as the view/controller layer in administering the e-commerce store. This is a bit of a challenge because the two systems behave quite differently when it comes to data access and administration. The e-commerce system deals with its data model virtually, using table gateways to retrieve and store data and "Managed Item Page Controllers" which act like virtual containers to retrieve data for editing (and they bind other view objects onto that managed data). The content system deals with its data model directly, using skins and a UI Policy to apply different view templates directly to managed content.
Since the e-commerce system can't use skins without some serious re-architecting, I decided that the content system should be more flexible, since skin assignment was already abstracted out into a UI Policy. I was able to update the UI Policy Manager to allow for skinless execution without affecting the rest of the site at all. It just meant that a content editing skin couldn't be applied. But that's OK! That's where this bridge layer comes in - to adapt the content data model to the page controllers of the e-commerce system. And, since the content system's policy based system is so descriptive and broken up into different responsibilities, instead of forcing them all on a single document or container object and its class, it's been pretty easy so far.
This in turn brings about a real sense of joy and accomplishment - that all of these systems that have been building up over the years, whether they stemmed from a customers request or from an internal solution to a nagging problem, are finally coming together as powerful building blocks. That the design ideals we've been working towards as a very small company are finally paying off, enough so that systems that a year or two ago could never live in the same web site together can now snap together if desired.
I knew I shouldn’t oughter-a-done-it, and I feel a little ashamed inside, but I went ahead andbit the appleused Cocoa bindings.
It was, I confess, a reaction to that terrible feeling you get when you’re faced with creating yet another NSTableView data source and delegate. I just couldn’t face another objectValueForTableColumn:blah:blah:whatever:.
How silly it seems now—what’s one more data source among so many?—but my emotions got the best of me, and I went ahead and created—yes, say it, admit it—an array controller in Interface Builder, and I bound that damn table.
And I liked it!
What Brent is talking about here is a new feature that appeared in Mac OS X 10.3, Cocoa Bindings, which is an automatic / dynamic Controller layer for the Mac OS X Cocoa framework. Most students of the MVC paradigm know that it's often the responsibility of the controller to mediate between the model (data) and the view (usually a user interface). It's an adaptation system - formatting / placing data in a cell, responding to a button click, etc. In a world where everything is done properly, different user interfaces can be placed on the same object/data model: HTML, "Heavy Client", etc.
But often, writing the controller can become tedious. As Brent mentions, writing another objectValueForTableColumn:blah:blah:whatever:
quickly loses its appeal along the way. Often, the controller layer is doing a very repetitive task: responding to a change in one of the other two layers (the view or the model) and propagating that change to the opposite layer. Enter Cocoa Bindings. It's descended from technologies previously used in Apple's enterprise technologies, WebObjects (Web, Java, and Web Services application server) and the Enterprise Objects Framework (a very powerful persistence system, primarily used in object-relational fashion):
Cocoa Bindings is a new set of technologies that snap right into the Model–View–Controller design pattern. It lets you hook up various View and Model objects and takes care of keeping them in sync. It does this by keying in a property name. When a view element is set up with a particular property name and a model object is also set up with the same property name, a binding can be made between the two. This will ensure that a value displayed on screen stays in sync with a particular value in the model.While it's not a groundbreaking technology, it's a nice offering from Apple for their primary desktop application framework. It should make it easier for Cocoa application developers to work on their application models and user interfaces while spending less time doing mundane glue work that fills most controller code.
A problem that Brent has, which plagues many developers, is that this is a feature available in the latest commercial release of Mac OS X (10.3), and he has tried to maintain support at least as far back as Mac OS 10.2. What makes this feature most interesting is that it's a developer-only benefit. I'm sure it helps application users in providing applications that might have a stronger control layer, but for the most part, and end-user does not see this feature. It's a 10.3 feature that's unseen. As a developer, at which point do you take advantage of framework and/or programming language features that may be beneficial to you, and when do you ignore them and for how long? I see this concern and worry all the time and in call camps, from Windows (especially now with .NET and Longhorn technologies floating about) to Python (2.0? 1.5? 2.1? 2.3?) and Zope 2.
Hmm. Anyways, Cocoa Bindings are cool. And more Apple Enterprise (aka, the old NeXT) technologies are finding their way into the desktop frameworks in the upcoming Mac OS X 10.4 in the form of new tools like Core Data. Abstract persistence on the desktop. Nice. Hopefully Core Data is easy to integrate with Mac OS X 10.4's Spotlight search system. Then it really will be a system that can compete with Longhorn's WinFS, which is still vaporware (and still might not ship with whatever ships as Longhorn).
While chasing links around and around this here world wide web, I landed in CNN's entertainment section. Mmmm. Bullet time! (Well, of sorts).
'Toy Story 3' in the works - Disney is apparently making moves to make Toy Story 3 without Pixar. Hm. That will put the nail in the coffin in that series about as quickly as it was put into the Batman series after Tim Burton and Michael Keaton left / were forced off. The upcoming "Batman Begins" should probably resurrect that franchise. The moral is: when the studio gets too eager to take over a project like this, things tend to turn out badly. And with how stale Disney's recent non-Pixar animated films have been, I don't expect Toy Story 3 to be a winner either. Pixar's got some magic that no one else really has.
So much for all that reality TV - Apparently broadcasters are finally starting to realize that forcing too much shitty reality TV down viewers throats is a turn-off. No shit! That said, I do enjoy watching the recaps of "My Big Fat Obnoxious Boss." I don't think I could stomach a full show, but the recaps are great. I guess I shouldn't be surprised that it's taken the networks (or audiences) this long to realize all of this crap is exactly that - crap.