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
I just found this JIRA and added my vote:
https://issues.apache.org/jira/browse/TAPESTRY-1818
No one is assigned to it and it doesn't have a 'Fix Version', so let
this follow-up illustrate the importance of the issue to me :).
chris
Chris Lewis wrote:
I understand, and I don't particularly w
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 tri
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 inves
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 t
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?
