Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2012-07-26 13:48:14

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

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

#2 2012-07-26 17:28:34

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

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

#3 2012-07-26 20:02:29

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

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

#4 2012-07-27 07:36:13

wet
Developer Emeritus
From: Schoerfling, Austria
Registered: 2005-06-06
Posts: 3,320
Website Mastodon

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:

  1. $thing does not contain a tag
  2. $thing is escaped through txpspecialchars()
  3. $thing is processed with parse()

Online

#5 2012-07-27 14:25:25

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

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:

  1. $thing does not contain a tag
  2. $thing is escaped through txpspecialchars()
  3. $thing is processed with parse()

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

#6 2012-07-29 05:12:09

wet
Developer Emeritus
From: Schoerfling, Austria
Registered: 2005-06-06
Posts: 3,320
Website Mastodon

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().

Online

#7 2012-07-30 11:48:46

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

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_splitting thing on each loop? Do it once, then evaluate the tree.

Offline

Board footer

Powered by FluxBB