Seems like a legit, if marginal (as you note), use case... though it's one that isn't broken by my change, since os/template was disallowed from <head> nodes to begin with :)
Personally I feel the best solution is to commit this right now (since it works and breaks no os/data-in-head cases of which I'm yet aware)... then when we switch to the Caja HTML parser, we can support elements in <head>. Seem reasonable? --j On Fri, Nov 13, 2009 at 12:36 PM, Paul Lindner <[email protected]> wrote: > What about using opensocial templates inside of the head section to say, > set > the title? > > <head> > <script type="text/os-data" xmlns:os=" > http://ns.opensocial.org/2008/markup > "> > <os:ViewerRequest key="viewer"/> > </script> > <title> > <script type="text/os-template" xmlns:os=" > http://ns.opensocial.org/2008/markup";> > Gadget for ${viewer.name.formatted} > </script> > </title> > </head> > > This does seem like an edge case though.. > > On Thu, Nov 12, 2009 at 9:06 PM, John Hjelmstad <[email protected]> wrote: > > > Found it. > > > > The OSData element was listed as acceptable in HEAD or BODY tags. For the > > reason mentioned aboave (Neko disallows HEAD children from having child > > elements), OSData elements must also show up in BODY. > > > > Patch: http://codereview.appspot.com/154106 > > > > Now the question is whether there are any circumstances in which it's > > absolutely required for OSData elements to appear in <head>. Thoughts? > > Louis? > > > > --John > > > > On Thu, Nov 12, 2009 at 8:21 PM, John Hjelmstad <[email protected]> > wrote: > > > > > Hey Paul: > > > > > > I've done a little digging into this, and have found out a few more > > > details. > > > > > > * Using the test file you've provided, the serialized version of the > > parsed > > > DOM turns out to be (schematically): > > > <head> > > > <link rel="..."> > > > <script type="os/data"></script> > > > <os:ViewerRequest.../> > > > </head> > > > <body> > > > <script type="os/template"> > > > ..os/template stuff > > > </script> > > > > > > * So the problem is the placement of the os/data tag outside of its > > > <script> block. That in turn happens due to code down in > > > org.cyberneko.html.HTMLTagBalancer.java line 665 and onward: > > > // close previous elements > > > // all elements close a <script> > > > // in head, no element has children > > > if ((fElementStack.top > 1 > > > && (fElementStack.peek().element.code == > > > HTMLElements.SCRIPT)) > > > || fElementStack.top > 2 && > > > fElementStack.data[fElementStack.top-2].element.code == > > HTMLElements.HEAD) { > > > final Info info = fElementStack.pop(); > > > if (fDocumentHandler != null) { > > > callEndElement(info.qname, synthesizedAugs()); > > > } > > > } > > > > > > This conditional causes callEndElement to prematurely close the > <script> > > > tag during processing of the os/data tag's contents (parsing > > > <os:ViewerRequest>). As noted in the comment, the semantic reason this > > > occurs is that the <script> element gets automagically foisted to > <head>, > > > and from there the code assumes that no child of <head> has children of > > its > > > own. > > > > > > That's about it. I'm trying to figure out why <link><script > > type="os/data"> > > > causes the <script> element to be placed in <head>, while removing > <link> > > > doesn't -- and stranger yet, putting the <script type="os/template"> > > element > > > after <link> doesn't cause it to be put in head (thereby exhibiting > this > > > behavior) as well. > > > > > > --j > > > > > > > > > On Wed, Nov 11, 2009 at 10:55 AM, Paul Lindner <[email protected] > > >wrote: > > > > > >> The problems started with this commit. Louis, could you have a look > at > > >> it? > > >> > > >> commit a98b18f181df9e78c2f90f6b02483e64c3c76a2a > > >> Author: lryan <lr...@13f79535-47bb-0310-9956-ffa450edef68> > > >> Date: Tue Sep 29 22:17:23 2009 +0000 > > >> > > >> Upgrade to Neko 1.9.13. Remove unused old Neko based parser > > >> > > >> git-svn-id: > > >> > > >> > > > https://svn.apache.org/repos/asf/incubator/shindig/tr...@82010913f79535-47bb-0310-9956-ffa450edef68 > > >> > > >> > > >> On Tue, Nov 10, 2009 at 11:03 AM, Paul Lindner <[email protected] > > >> >wrote: > > >> > > >> > If there are tags preceding the test/os-data script tags parsing > > fails. > > >> It > > >> > appears that the DOM parsing mangles the singular tags in the block > > and > > >> > somehow sees them as an open/close tag combo. > > >> > > > >> > A patch that reproduces the problem follows. I'll do a git bisect > > later > > >> > today to see where this was introduced. > > >> > > > >> > > > >> > diff --git > > >> > > > >> > > > a/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-socialmarkup.html > > >> > b/java/gadgets/src/test/resources/org/apache/shindig/gadgets/p > > >> > index c7fa769..f38663b 100644 > > >> > --- > > >> > > > >> > > > a/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-socialmarkup.html > > >> > +++ > > >> > > > >> > > > b/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-socialmarkup.html > > >> > @@ -1,3 +1,5 @@ > > >> > +<link href="moo"></link> > > >> > + > > >> > <script type="text/os-data" xmlns:os=" > > >> > http://ns.opensocial.org/2008/markup";> > > >> > <os:ViewerRequest key="viewer"/> > > >> > </script> > > >> > @@ -14,4 +16,4 @@ > > >> > > > >> > <span>Some content</span> > > >> > > > >> > -<div><!-- foo -->bar<!-- baz --></div> > > >> > \ No newline at end of file > > >> > +<div><!-- foo -->bar<!-- baz --></div> > > >> > > > >> > > > > > > > > >
