Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Drawback of not parsing the content of a txp tag?
Suppose we call
<txp:some_tag>
content
</txp:some_tag>
and the content
contains no tags at all, which can be detected by regex. Will there be any negative effect of not parse()
ing the content
? While testing etc_query plugin, I have noticed that this divides the runtime by ~2, which is quite noticeable with large data, especially with loops. And finally the whole thing gets parsed anyway, probably with the secondpass
.
Offline
Re: Drawback of not parsing the content of a txp tag?
etc wrote:
Will there be any negative effect of not
parse()
ing the content?
If the contained statement has no tags at all, then no. As I see it, you can do that without issue in such case where the statement contains no tags. I’m not saying I would do this personally, actually I would categorize this as a hack-ish method. But you do what you do.
And finally the whole thing gets parsed anyway, probably with the
secondpass
.
That is the reason behind of it.
While secondpass is there, please keep in mind that you can’t relay on it. The second parser run is used as a feature, and leaving a parser call out, while it seemingly still parses the contained statement, it may break certain child tags that expect two parser calls which they won’t get (e.g. tags that do binding, or Textpattern’s list pagination).
As secondpass goes, hopefully in the future it gets dropped altogether from the source, or is at least restricted in a behavior.
Offline
Re: Drawback of not parsing the content of a txp tag?
Thank you for the explanation, this secondpass
always intrigued me.
Gocom wrote:
While secondpass is there, please keep in mind that you can’t relay on it.
I don’t, it’s a side effect.
Offline
Re: Drawback of not parsing the content of a txp tag?
etc wrote:
which can be detected by regex.
As a rule of thumb you have to assert at least one of these three rules:
$thing
does not contain a tag$thing
is escaped throughtxpspecialchars()
$thing
is processed withparse()
Offline
Re: Drawback of not parsing the content of a txp tag?
wet wrote:
As a rule of thumb you have to assert at least one of these three rules:
$thing
does not contain a tag$thing
is escaped throughtxpspecialchars()
$thing
is processed withparse()
Thank you for the reply, I am trying to assert the n°1, otherwise $thing
is parsed. What is txpspecialchars()
, I do not find it in PHPXref? I do not think it’s an option, since sometimes (often) $thing
contains tags.
Offline
Re: Drawback of not parsing the content of a txp tag?
etc wrote:
What is
txpspecialchars()
, I do not find it in PHPXref?
It’s a shell around htmlspecialchars
which we will introduce in Textpattern 4.5. For older releases you may use htmlspecialchars
as well.
I do not think it’s an option, since sometimes (often)
$thing
contains tags.
Then use parse()
.
Offline
Re: Drawback of not parsing the content of a txp tag?
That’s what I would suggest (à la splat()
function): $thing
is parsed only if <txp:
pattern is detected therein. This would make no real difference for “single” tags, like <txp:variable />
, but in “list” tags, like <txp:category_list />
, if we check for the presence of <txp:
in $thing
before the loop and parse($thing)
only if something is detected, the runtime could be reduced. Compare
$thing = '<span>thing</span>';
for($i = 0; $i < 100; $i++) echo parse($thing);
with
$parse = strpos($thing, '<txp:') !== false;
for($i = 0; $i < 100; $i++) echo $parse ? parse($thing) : $thing;
and you pass from 0,0015 to 4E-5 seconds.
This is a marginal improvement, of course, since most containers contain <txp:
tags. Possibly, parse()
should be split into two parts: parse and construct the $thing
’s tree before the loop, then evaluate it while looping. If we consider something like
<txp:category_list wraptag="ul" break="">
<li<txp:if_category name='<txp:category />'> class="active"</txp:if_category>>
<txp:category title="1" link="1" />
</li>
</txp:category_list>
what is the point of preg_split
ting thing
on each loop? Do it once, then evaluate the tree.
Offline