Re: [TYPO3-english] COA always true when used in if.isTrue.cObject?

2018-03-06 Thread tcrass

Hi Stephan,

thank you for your detailed and instructive reply, in particular the 
link to the rendering process chart. I'm sorry, though, you found my 
example too long since I really tried to break down my actual problem 
into a minimum working example, trying to use self-explaining object names.


Anyway, I'm not convinced that isTrue evaluates to true just due to some 
placholder strings for non-cacheable objects since I get exactly the 
same output when either


a) replacing the COA_INTs with plain COAs and/or
b) entirely removing the TEXT object from the supposedly empty COA(_INT).

(And yes, I did clear the cache after applying those changes... ;)

It seems that if.isTrue.cObject < some COA(_INT) always yields true, no 
matter whether the content array is cacheable or not and/or does contain 
anything at all.
So... is there any way to use COA(_INT)s in conditional typoscript 
expressions and make decisions based on whether they render as empty or 
non-empty string?


Cheers --

Torsten



___
TYPO3-english mailing list
TYPO3-english@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english


Re: [TYPO3-english] COA always true when used in if.isTrue.cObject?

2018-03-06 Thread Stephan Schuler
Hey there!


tl;dr:

It's about caching.


The logical explanation:

TEXT is potentially cached, COA_INT is not.
Think about the second request. TEXT is supposed to not be recalculated but 
taken from cache. How can that depend on COA_INT, which might calculate 
differently compared to how it resulted during the previous request?


The technical explanation:

Wow, I'm old. Back in the days, there used to be something called the "TYPO3 
Frontend Rendering Process".
Here it is:
https://buzz.typo3.org/uploads/media/TYPO3_Frontend_Rendering_Process_v1.5.pdf

TEXT is calculated on step 31 ("generate the page"), COA_INT as well as 
USER_INT are calculated on step 32 ("include non-cached objects").

Although that diagram is accurate for v4.1 and a lot of things have change 
since then, there's still a lot a lot of truth in that picture :).


The very technical explanation:

During step 31 of the previous diagram, all COA_INT and USER_INT sections are 
assumed as placeholder strings.
It's something like ""

See:
https://github.com/TYPO3/TYPO3.CMS/blob/7254650107f48732b963d5ef8c6838bdd02ff1bd/typo3/sysext/frontend/Classes/ContentObject/ContentObjectArrayInternalContentObject.php#L38

That's what goes to the cache: The string output of  the cachable part of your 
website filled with a couple of those INT_SCRIPT placeholders.

During step 32, all INT scripts are finally executed and their placeholder are 
replaced by the per-request individual result.

So I assume the TypoScript "if" part just casts 
"" to true.


Regards,



Stephan Schuler
Softwareentwickler | netlogix Web Solutions

Telefon: +49 (911) 539909 - 0
E-Mail: stephan.schu...@netlogix.de
Web: websolutions.netlogix.de




Case Study: 1&1-Vertriebspartnerportale – prämiertes Neos-Projekt
Lesen Sie, wie wir mit unseren Projektpartnern eine moderne, ausbaufähige 
Grundlage auf Basis von Neos CMS für den Betrieb der 
1&1-Vertriebspartnerportale schaffen konnten und uns so den Neos Award Gold für 
herausragende Projekte sicherten. Mehr 
erfahren…https://websolutions.netlogix.de/referenzen/1und1





netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: i...@netlogix.de | Web: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Matthias Schmidt




Von: typo3-english-boun...@lists.typo3.org 
 im Auftrag von tcrass 
Gesendet: Dienstag, 6. März 2018 22:22
An: typo3-english@lists.typo3.org
Betreff: [TYPO3-english]  COA always true when used in if.isTrue.cObject?

Dear all,

I've observed some -- at least: to me -- quite puzzling behavior in my
Typo3 7.6 installation. Consider the following TypoScript:

lib.textWithContent = TEXT
lib.textWithContent.value = foo

lib.textWithoutContent = TEXT
lib.textWithoutContent.value =

lib.coaWithContent = COA_INT
lib.coaWithContent {
   10 = TEXT
   10.value = foo
}

lib.coaWithoutContent = COA_INT
lib.coaWithoutContent {
   10 = TEXT
   10.value =
}

page.10 = TEXT
page.10 {
   value = This should be visible (TEXT)...
   if.isTrue.cObject < lib.textWithContent
}

page.20 = TEXT
page.20 {
   value = This should be invisible (TEXT)...
   if.isTrue.cObject < lib.textWithoutContent
}

page.30 = TEXT
page.30 {
   value = This should be visible (COA)...
   if.isTrue.cObject < lib.coaWithContent
}

page.40 = TEXT
page.40 {
   value = This should be invisible (COA)...
   if.isTrue.cObject < lib.coaWithoutContent
}

I'd expect entries 20 and 40 of the page array to not show up in the
rendered page, but alas! here's what I get:

This should be visible (TEXT)...This should be visible (COA)...This
should be invisible (COA)...


Obviously, the empty COA object at lib.coaWithoutContent is considered
being not-empty in page.40.if.isTrue.cObject < lib.coaWithoutContent.

Any explanation?

Cheers --

Torsten
___
TYPO3-english mailing list
TYPO3-english@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
___
TYPO3-english mailing list
TYPO3-english@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english