Sometimes, GOTO just feels appropriate. I'm writing some dispatch code that should short circuit once I've found the case to dispatch. Abstracting out the code and putting and putting it into a self-contained function would work - I could just put in an early return - or doing something with a local escape continuation would as well, but I'm in JavaScript, and that would be excessive abstraction. I've resigned myself to a labeled jump and dirty bit. Yuck.
Side note: working with the CANVAS tag feels like a step back to the dark ages (~1997?). Now we have to recreate THE ENTIRE FLASH RUNTIME AND ENVIRONMENT in order to do basic vector processing and event manipulation. My basic approach is to make a scene graph, catch all mouse events, and then dispatch with respect to the graph (forgoing quad-tree style optimizations for now). The trick is that I use Flapjax for my objects: dispatch, while ugly, is actually an event injection into a channel of the scene object of interest. The object is defined compositionally/reactively with respect to these channels. It also has a render function to imperatively draw based on the current values. The rendering process listens to scene graph objects to perform demand-driven redraws per input event, not output value change, and calls the draw functions of all functions, because that's what canvas tags force you to do without twisted hackery. For now, the renderer listens for any change to a scene graph object - later I'll fine-tune objects for more fine-tuned registration. Tomorrow, the plan is to integrate Google Gears into the picture... this weekend - lazy continuation capturing and explicit store serialization :D
2 comments:
Yeah, the canvas sucks. At least it did a couple of years ago. No events = teh sux. Have you considered using SVG instead? All real browsers support it, and the Unmentionable One supports some kind of proprietary equivalent. This is what the Dojo toolkit does. I believe you get an actual DOM from SVG, and, with that, events and so forth.
The kicker was that the canvas tag doesn't really support text - I want to create a collaborative, versioned, back-button new-window friendly charting widget to get a feel for these sorts of things, and did not expect that to be the stumbling block (... we don't appreciate what we have until it's gone...). The context stack was clunky for me in Processing, and still is here (horrible GL artifact?).
I began playing with Dojo charting but found setup to be excessive, without even setting up data source. Flex is supposed to have a stellar charting system, but I want to stay in the JS ecosystem. SVG straight up would have made more sense - and I could have reused more of my event libraries :) Integration to the DOM was a big concern when incorporating SVG into browsers, so I feel dumb for not looking at it (the last was years ago when it was slow slow slow). Maybe it's high time somebody ported prefuse/flare to JavaScript. The reason I went through with the canvas tag exercise was that I'm trying to figure out just how many threads I can really use in a browser, and thought it'd be a good exercise to build such a system using data flow on top of, effectively, a pixel buffer.
Now I'm scratching my head about ORM and reactivity for google gears, as well as cross-tab data pushes (foreign function triggers would be nice!). The primitives seem to be mostly in place, but not much else. It would be cute to see how the bidirectional programming / lense stuff would play here.
Post a Comment