Textpattern CMS support forum

You are not logged in. Register | Login | Help

#21 2014-11-18 13:00:20

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,495
Website

Re: Making plugins first-class citizens

ruud wrote #285888:

You’d still get into problems with a plugin that registers the “geo” prefix combined with those <geo:lat> tags.

We should probably reserve some of the well-known prefixes as off-limits. And someone had better tell geoff77 that his prefix is on the banned list :-o


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

Offline

#22 2014-11-18 13:09:10

etc
Developer
Registered: 2010-11-11
Posts: 3,017
Website

Re: Making plugins first-class citizens

Bloke wrote #285891:

And someone had better tell geoff77 that his prefix is on the banned list :-o

And someone should sue tools.ietf.org/html/draft-lozano-tmch-smd-02 for using smd prefix ;)


etc_[ query | search | pagination | date | tree | cache ]

Offline

#23 2014-11-18 13:21:43

etc
Developer
Registered: 2010-11-11
Posts: 3,017
Website

Re: Making plugins first-class citizens

What about <smd::magic /> scheme?


etc_[ query | search | pagination | date | tree | cache ]

Offline

#24 2014-11-18 13:30:38

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,495
Website

Re: Making plugins first-class citizens

etc wrote #285892:

And someone should sue tools.ietf.org/html/draft-lozano-tmch-smd-02 for using smd prefix ;)

Oh, now the gloves are well and truly off! How dare they ;-)

The double-colon, or some other unique identifier, is a good suggestion for side-stepping other namespace clashes. Not sure how the regex would need to be altered, but that’s not my area of expertise.

Anyone have any other cool ideas?


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

Offline

#25 2014-11-18 22:48:56

ruud
Developer emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

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

#26 2014-11-27 22:46:28

ruud
Developer emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

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.2115

Offline

#27 2014-11-28 10:10:20

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,495
Website

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

Offline

#28 2014-11-28 19:18:52

ruud
Developer emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

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

#29 2014-11-28 23:25:21

etc
Developer
Registered: 2010-11-11
Posts: 3,017
Website

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?)


etc_[ query | search | pagination | date | tree | cache ]

Offline

#30 2014-11-29 12:33:44

ruud
Developer emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

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

Board footer

Powered by FluxBB