Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#16 2014-11-17 21:51:22
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Making plugins first-class citizens
ruud wrote #285853:
I’d trade that for being able to write templates that are more easy to read.
Hear, hear … one of Textpattern’s great strengths.
Offline
Re: Making plugins first-class citizens
gomedia wrote #285854:
Hear, hear … one of Textpattern’s great strengths.
Which is one of the main reasons I was attracted to Textpattern and why I am still here.
Offline
Re: Making plugins first-class citizens
Guys, I hope you know what you are doing. There are many common 3-letters xml namespaces (rdf, owl, geo, …). By registering some geo_plugin, you are seriously compromising the possibility to export an article (with, say, rah_eo) as
xml
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<geo:Point>
<geo:lat><txp:custom_field name="lat" /></geo:lat>
<geo:long><txp:custom_field name="long" /></geo:long>
</geo:Point>
</rdf:RDF>Provide at least the possibility to “unregister” some namespaces in parse(), etc. We can still call <txp:geo_lat /> if needed.
Please get me right, I like the idea, but life is life.
Offline
Re: Making plugins first-class citizens
When registering tags it’s possible to collect a list of used prefixes and only allow only those to be parsed. You’d still get into problems with a plugin that registers the “geo” prefix combined with those <geo:lat> tags.
In addition to that, we could limit this new prefix stuff to tags that are registered. That should motivate plugin authors to update their plugins ;)
Offline
Offline
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.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Making plugins first-class citizens
Bloke wrote #285891:
And someone had better tell
geoff77that 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 ;)
Offline
Offline
Re: Making plugins first-class citizens
etc wrote #285892:
And someone should sue tools.ietf.org/html/draft-lozano-tmch-smd-02 for using
smdprefix ;)
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.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
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.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
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