On Wed, Aug 6, 2008 at 11:34 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > This proposal effectively enables the renderer to become a multi-pass > compiler for gadget content (essentially, arbitrary web content). Such a > compiler can provide several benefits: static optimization of gadget content > (auto-proxying of images, whitespace/comment removal, consolidation of CSS > blocks), security benefits (caja et al), new functionality (annotation of > content for stats, document analysis, container-specific features), etc. To > my knowledge no such infrastructure exists today (with the possible > exception of Caja itself, which I'd like to dovetail with this work).
Caja clearly provides a large chunk of the code you'd need for this. I'd like to hear how we'd manage to avoid duplication between the two projects. A generalised framework for manipulating content sounds like a great idea, but probably should not live in either of the two projects (Caja and Shindig) but rather should be shared by both of them, I suspect. > c. Add Gadget.getParsedContent(). > i. Returns a mutable GadgetContentParseTree used to manipulate Gadget > Contents. > ii. Mutable tree calls back to the Gadget object indicating when any > change is made, and emits an error if setContent() has been called in the > interim. In Caja we have been moving towards immutable trees...
