Not to beat a dead horse, but I (completely by accident) ran into this
bug again as I was testing my component and was using internal styles -
one of the rules used the direct child operator '>'. It took me an hour
before I realized why it wasn't working - it was being filtered as an
entity for the same reason my JS was.
Chris Lewis wrote:
I understand, and I don't particularly want to get into a discussion
about pros/cons of that, but at the moment that may leave me stranded.
The correct way to handle this would be to declare the script block as
CDATA instead of PCDATA (I'm not sure why its not this way by
default), and so I tried the following in a tml file:
<script type="text/javascript"><![CDATA[
alert('>');
]]></script>
Unfortunately I was greeted with an java.lang.IllegalStateException,
saying "Not implemented yet: CDATA[ alert('>'); ]". This suggests to
me that the problem is on the radar, so that's good. I wonder if you
have any idea when this might be implemented, and is there already a
JIRA for it?
In my opinion the script block generated by the underlying head
builder should be CDATA by default. I think its logical to assume that
JS code will almost always have these characters, which is why I'm
baffled that the spec declares script blocks to be of PCDATA
(http://www.w3.org/TR/xhtml1/#h-4.8). Of course I believe (and adhere
to) that logic doesn't belong in documents and should be in external
files, and my component is written in this manner. However it needs
some wiring, and at the moment I'm unable to do this wiring.
Sincerely,
Chris
Howard Lewis Ship wrote:
Well, we are going for XHTML compliance with Tapestry, so the
characters need to be escaped. I supposed we could bypass that (we
already generate SGML style HTML rather than well formed XML, based on
the output doctype).
On Nov 13, 2007 8:21 AM, Chris Lewis <[EMAIL PROTECTED]> wrote:
I've investigated this issue and realized that the problem isn't
receiving the unfiltered character, but writing it to the client.
Here's
the situation: my component receives a string parameter that is simply
passed to a javascript object. This parameter is a css selector rule as
supported by the prototype library:
http://www.prototypejs.org/api/element/getelementsbyselector
http://www.prototypejs.org/api/utility/dollar-dollar
The javascript object uses this rule to locate the set of elements upon
which it should operate, allowing greater control of how a user
structures their template markup. So in my case I want to select all of
the immediate child divs, I can use the rule '> div'. The problem is
that when the final markup sent to the browser, this string is filtered
as '>' - this breaks my rule. After some digging and *some real time
discussion with other developers (fanf) in the IRC channel (#tapestry
irc.freenode.net)*, I realized the problem is a bit deep.
To add my scripts my component employs the PageRenderSupport
environmental. Longer explanation made short, this ends up in my script
code (added by addScript()) being added to the document using
Element#text. This method does the filtering, and there's nothing I can
do about it.
The only option I think I have is to contribute by own
implementation of
PageRenderSupport. However since I can't just extend
PageRenderSupportImpl and delegate to it (its an internal service),
this
seems to leave me stranded with the task of reimplementing it from
scratch.
Obviously I don't want to do that, so I'm asking for some input from
those with a deeper knowledge. How can this be done better? Does it
makes sense to use Element#text instead of Element#raw in
DocumentHeadBuilderImpl#updateDocument, since where writing script code
and not markup?
sincerely,
chris
Chris Lewis wrote:
My component takes a parameter with a default binding prefix of
'literal'. This parameter needs to be able to receive strings with
characters like '>', but apparently the literal prefix causes them to
be converted to entities. How can I pass unfiltered characters to my
component as a parameter?
Thanks,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
