Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Making plugins first-class citizens
Bloke wrote #285891:
We should probably reserve some of the well-known prefixes as off-limits.
There really should be a prefix that is reserved for private use (non-distributed plugins). Much like the 192.168.. / 10...* IP ranges. Perhaps: abc or loc or lcl or xxx (well, perhaps not that one).
Another way to deal with the <geo:loc> type tags would be to make it a preference, so you can disable this new prefix parser and fall back on the old parser. Much like being able to disable short tag support in php.ini. Simpler than adding a whitelist/blacklist of prefixes.
Offline
Re: Making plugins first-class citizens
New and improved patch, which tests for a preference ‘allow_short_tags’ to determine whether to parse only tags with the txp: prefix or also those with other 3 char prefixes.
And new EvalElse() benchmarks, tested with the following strings:
$thing = 'some very long text that does not contain an else tag';
$thing = '<txp:else />some very long text that does contain an else tag';
$thing = 'some very long text that does contain an else tag... but no other tags<txp:else />';
$thing = 'some <b>very long</b> text: that does contain an else tag and other tag <txp:else />';
$thing = 'some very long text that does contain an else tag and <txp:other /> tag <txp:else />';
$thing = '<txp:other />some very long text that does contain an else tag and other tag <txp:else />';
$thing = '<txp:tag1><txp:tag2><txp:tag3><txp:tag4><txp:tag5><txp:tag6><txp:tag7><txp:tag8><txp:tag9><txp:tag10></txp:tag10></txp:tag9></txp:tag8></txp:tag7></txp:tag6></txp:tag5></txp:tag4></txp:tag3></txp:tag2></txp:tag1><txp:else />'First column is the TXP 4.5.x EvalElse(). The second column the new EvalElse(). Top half was tested with condition ‘true’, the bottom half with condition ‘false’. I’ve optimized it quite a bit, compared to the previous patch.
--
0.1599 0.1957
0.3094 0.5112
0.3128 0.5201
0.3195 1.3851
1.7837 1.8216
1.7739 1.8519
9.3551 8.0615
0.1574 0.1940
0.3719 0.4972
0.3716 0.4906
0.3850 1.5544
1.9486 1.9683
1.9231 1.9702
9.6688 8.2115Offline
Re: Making plugins first-class citizens
ruud wrote #286100:
New and improved patch
You spoil us. That’s terrific, thank you.
I’ll let Oleg chime in on how this version fares alongside XML, but I don’t see any issues aside from the fact that it’s now a binary decision: if using XML documents with three letter namespaces, you cannot use Txp short tags. Or, well, you can, but caveat utilitor.
I’ll do some testing on my local setup too and if this meets approval with the others I’ll add the pref and merge the patch in.
Thanks again for your hard work on this and the optimisations. That last example comes in faster :-)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: Making plugins first-class citizens
Bloke wrote #286111:
I’ll let Oleg chime in on how this version fares alongside XML, but I don’t see any issues aside from the fact that it’s now a binary decision: if using XML documents with three letter namespaces, you cannot use Txp short tags. Or, well, you can, but caveat utilitor.
It doesn’t have to be binary. If you don’t make $prefix a static variable, you could modify the pref during parsing and disable it only where needed. Downside is that it’s around 10% slower. I didn’t think it was worth doing that, because I suspect that only a small minority of users is using XML, but perhaps Oleg can shed some light on this.
That last example comes in faster :-)
Without the pref added, the last three were faster and the first one was equal. It was surprising to see how much faster $str[0] is compared to substr($str, 0, 1).
Offline
Re: Making plugins first-class citizens
Me what, I’m only repairing the primus… Well, given the overall txp usage statistics, the XML users are close to none, though dc: and atom: are needed in custom rss feeds. But we are going to conquer the world, right?
I would choose <pfx::tag /> scheme and not mind dropping <pfx::else /> support if necessary. A pref is better than nothing, but if you start with <pfx:tag /> enabled, and then change your mind (or need to add an XML feed), you’ll have to rewind everything to <txp:pfx_tag />.
This said, Ruud’s optimization efforts/results are very appreciated, save for n4 (why?)
Offline
Re: Making plugins first-class citizens
n4 tests a EvalElse optimisation that triggers when there is no TXP before the <txp:else /> tag. That is simplified to the case where there is no : before the <txp:else /> tag, because checking for a random prefixed tag would require a regex, which would slow down n5 – n7. Basically, n4 is handled like n5 in the new parser, causing n4 to be slower, but n5 remains relatively fast.
Offline
Re: Making plugins first-class citizens
What makes me hesitate too, is that putting
if(strpos($thing, '<txp:') === false) return $thing;at the very beginning of parse() (and the like), divides the runtime by 5 if $thing does not contain <txp:tags />. This optimization would not be possible with “short” tags.
Offline
Re: Making plugins first-class citizens
I’ve been following this thread since the beginning. Although I can understand the idea of fewer keystrokes I am wondering if this is just aimed for programmers who have to type all the time. In my view – although this would be a good update it would also mean that many plugins will just stop working (correct me if I am wrong).
Wouldn’t it be more productive for now to focus on real updates of the txp system such as extending the custom fields?
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Making plugins first-class citizens
colak wrote #286329:
it would also mean that many plugins will just stop working (correct me if I am wrong).
It will have no impact on the behaviour of existing plugins, aside from turbo-charging them with their very own else tag. This enables site admins to match up a plugin’s container with a plugin-prefixed else tag, which improves template readability. Aside from that, yes, less typing if you wish to take advantage of it, otherwise it’s business as usual.
The new syntax would merely be offered as an option for those that prefer it.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: Making plugins first-class citizens
etc wrote #286328:
What makes me hesitate too, is that putting
if(strpos($thing, '<txp:') === false) return $thing;...at the very beginning of
parse()(and the like), divides the runtime by 5 if$thingdoes not contain<txp:tags />. This optimization would not be possible with “short” tags.
Using this, has the same effect in most cases:
if(strpos($thing, ':') === false) return $thing;Offline
Re: Making plugins first-class citizens
Bloke wrote #286330:
turbo-charging them with their very own
elsetag.
only if the plugin is already <txp:else />-aware, right?
ruud wrote #286334:
Using this, has the same effect in most cases:
if(strpos($thing, ':') === false) return $thing;...
Not if $thing contains http:, for example, which is rather common.
Offline
Re: Making plugins first-class citizens
etc wrote #286335:
only if the plugin is already
<txp:else />-aware, right?
Yes.
Not if
$thingcontainshttp:, for example, which is rather common.
It’s not that common in the simple if/else constructs that this optimisation targets. I’ve checked two websites (one of them being TXP.org). I could find only one case where the : optimisation would fail. In around 95% of situations where the optimisation should save time it works just fine.
Offline