Feature #23762
closed
Typoscript issue on values using "internal chars" in string-sequence
0%
Description
I noticed that TYPO3 seems to have problems on using internal-chars within dataWrap'ped typoscript-values.
Internal-Chars are f.e.:
the pipe "|"
curls like ( ) { }
The only "hack" figured out by myself is to use a LOAD_REGISTER where ever possible to avoid using the chars them-self within Typoscript values/wraps.
There should be a more programmer friendly way to solve this!
My recommendation: Make Typoscript handle "escapes" like they work in RegEXP (escape-sequences f.e. "\").
f.e. output curls: \{ \( <-- THESE WILL BE HANDLED AS TEXT IN TS!
Example:
DOES NOT WORK:
-- TS-Setup --
10 = TEXT
10.dataWrap = {THIS SHOULD BE SHOWN AS TEXT WITH CURL}
20 = TEXT
20.dataWrap (
<script language="text/javascript">
// Curls may be very annoing using Javascript with InsertData/Registers in Typoscript!!!
// example:
function test() {
// THIS WILL NOT RENDER CORRECTLY WITH CURLS!
}
// another example:
var JSON={value:test} // CRASH: DOES NOT RENDER OUT AS SHOWN HERE!
</script>
)DOES WORK
10 = COA
10.1 = LOAD_REGISTER
10.1.openCurl = {
10.1.closeCurl = }
10.10 = TEXT
10.10.dataWrap = {register:openCurl}THIS SHOULD BE SHOWN AS TEXT WITH CURL{register:closeCurl}
20.20 = TEXT
20.20.dataWrap (
<script language="text/javascript">
// Curls may be very annoing using Javascript with InsertData/Registers in Typoscript!!!
// example:
function test() {register:openCurl}
// THIS HACK WILL WORK!
{register:closeCurl}
// another example:
var JSON={register:openCurl}value:test{register:closeCurl}
</script>
)I hope this Hack will work for anybody having the issue like me.
(issue imported from #M16881)
Updated by Gabriel Kaufmann almost 14 years ago
I can't provide a patch yet as I wasn't able to "dig" into the TYPO3-Core for rendering Typoscript yet ;-)
I hope there will be a core-developer reading this who is able to provide a patch out of his hands very quick instead.
Updated by Jo Hasenau almost 14 years ago
As long as you don't provide any data to be inserted within the dataWrap, you should not use it anyway.
10 = TEXT
10.dataWrap = {THIS SHOULD BE SHOWN AS TEXT WITH CURL}
no need for a dataWrap here, since this would be done by
10 = TEXT
10.value = {THIS SHOULD BE SHOWN AS TEXT WITH CURL}
same with the second example. There is no data to be inserted, so you should go for "value" instead of "dataWrap"
Of course there might be situations where you would have to insert data and use curly braces as well, but this could be solved easily like this:
10 = COA
10 {
10 = TEXT
10 {
field = fieldname
dataWrap = | {field:another_fieldname}
wrap3 = {|}
}
20 = TEXT
20 {
field = yet_another_fieldname
dataWrap = |{field:a_last_fieldname}
wrap3 = {|}
}
}
Updated by Gabriel Kaufmann almost 14 years ago
@ Jo Hasenau (reporter)
I totally agree, that some of my examples wouldn't need a dataWrap. These examples were not correct. In fact in each of the dataWrap's there should be any data-values which makes sense for the dataWrap-use instead of a plain value!
Thank you for your suggestion using wrap3 for the curls. But in fact there are situations which will make the typoscript unnessecarily blow-up because of that syntax. Imagine the rendering of more-complex javascript that has to be rendered using typoscript instead of static-inclusion. I don't think it would make sense to use hundred of COA and TEXT-wrap to solve the curls.
Of couse in usual way it makes sense to use static-external javascripts where ever possible. Also there shouldn't be more dataWrap than really needed (for performance reasons). But in some case this happens for complex data that has to be rendered into javascript-structures.
So why wouldn't it make sense to think about escaping for typoscript-internal values?
Updated by Jo Hasenau almost 14 years ago
If you want to provide JavaScript with some values inserted, this would be a job for the TEMPLATE element. Just use your JS as the template file and fill in some markers to be replaced with the dynamic values.
Of course it could make sense to escape "internal" characters while parsing TypoScript, but I don't see too many use cases, that could not be solved easily with the current parser and some existing elements.
Updated by d.ros no-lastname-given almost 12 years ago
- Target version deleted (
0)
Here´s the usecase that should be common -> JS Libraries from CDN and their fallback.
masterscripts.allWrap = <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script><script>window.jQuery &124;&124; document.write('<script src="fileadmin/developer/Templates/mcdn/jquery/jquery.min.1.7.2.js"><\script>')</script> |
Masking with
&124;works buts V8 from Chrome matches an illigal character.
Cheers
Updated by Mathias Schreiber almost 10 years ago
- Tracker changed from Bug to Feature
- Description updated (diff)
- Status changed from New to Rejected
Sorry, but implementing this is just too big of a task while there are plenty of alternatives around.
You can use TEMPLATE, FLUIDTEMPLATE etc for these kinds of things.
The Typoscript Parser is a brittle, gigantic thing.
I had a look at this in regards of the escape sequence idea but that way we'd need to fiddle around with the strings or regex things.
I tried escaping { and it resulted in more than 50% rendering overhead.
Sorry for the bad news, but no... can't be done.