On Sat, Apr 11, 2009 at 4:03 AM, Chris Chabot <chab...@google.com> wrote:
> Hey All, > > I've committed my big change to the gadget rendering that switches it over > from a plain old 'output text strings' to a completely DOMDocument based > model (ie: the gadget's document is parsed using the dom doc, and all the > js > and css are injected through dom functions (appendChild/etc)). > > The upside of this change is that the same logic is re-usable for the > proxied content parsing, where the same js and css needed to be injected > (even though the remote content can have a proper <html><head><body> > structure or not, valid existing js/css or not, etc). So by using the DOM > functions, libxml sorts all this out for us and always makes a proper html > document out of it, also it significantly reduced duplicate code paths and > the end result is a much cleaner implementation. > > The downside is that the output is now slightly different then before, most > noticeably, 'broken' html will come out slightly different then before > (because libxml 'fixes' it), which has the potential of breaking gadgets. > > I've tested my standard set of gadgets (Budy Poke, iLike, OSDA, Compliance > Test, etc) and they all work fine through the new parser, but if you have > any gadgets to test with, I would love to hear how they work on the new > renderer. http://www.partuza.nl/ now runs this new implementation, so > that's > probably the easiest place to test right now. The java code was already doing this, and has been for ~6 months. So far no complaints. One thing to watch for is preservation of the doctype, as the spec requires it. We're doing something similar with CSS as well (to facilitate rewriting), and that did cause some issues, mostly because we were using a fairly strict CSS parser. > > > Thanks! > > -- Chris >
