You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Chris Lewis <ch...@bellsouth.net> on 2007/11/12 20:01:10 UTC
T5: entities in literal:
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: entities in literal:
Posted by Chris Lewis <ch...@bellsouth.net>.
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 <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: entities in literal:
Posted by Chris Lewis <ch...@bellsouth.net>.
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 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 <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: entities in literal:
Posted by Chris Lewis <ch...@bellsouth.net>.
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 <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>
>
>
>
Re: T5: entities in literal:
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: entities in literal:
Posted by Chris Lewis <ch...@bellsouth.net>.
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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>