Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Making plugins first-class citizens
Gentlemen, I’m still uncomfortable with short tags. Imagine that you use some <geo:shorttag />, then the day you need XML geo namespace, you are in trouble. Wrapping it in <txp:noparse /> looks weird, especially if some of its attributes are txp tags. I would rather adopt <abc|shorttag /> or some other scheme.
Offline
Re: Making plugins first-class citizens
For that corner case, it wouldn’t be hard to write a small plugin that provides a container tag which protects certain XML namespaces (or even anything except the txp namespace), while still allowing TXP tags in the attributes.
Offline
Re: Making plugins first-class citizens
It’s not so great for code readability, especially if the code is written by someone else (or by yourself 6 months ago). And edge cases can become mainstream, think of EPUB that mixes namespaced HTML, SVG, MathML, … But I won’t insist, a binary on/off preference will suffice.
I’m way more excited about the admin-side parsing and cache, if you have time.
Offline
Re: Making plugins first-class citizens
I have time.
Stef, should I create a patch for TXP 4.5.* or for 4.6?
Offline
Re: Making plugins first-class citizens
It should be for 4.6. Thanks.
Offline
Re: Making plugins first-class citizens
etc wrote #289475:
Gentlemen, I’m still uncomfortable with short tags.
I don’t like this at all either. If you want to change the prefix, or make it configurable, you should either:
- Shorten the global namespace prefix.
- Use different namespace separator that doesn’t collide with XML.
As the implementation is now, I wouldn’t recommend putting it in to core. In addition to that you, the prefix if made configurable, should be registered through the tag registry, rather than being patched in by rewriting the tag called from pool.
Last edited by Gocom (2015-04-12 22:43:43)
Offline
Re: Making plugins first-class citizens
Using the tag registry works only if all plugin authors register the tag with the short prefix as well. The solution proposed here works without having to modify any plugins.
I’m not a fan of simply shortening the prefix.
Would you consider changing the namespace separator for the core TXP tags as well?
Offline
Re: Making plugins first-class citizens
What I like about the prefix is
- you know that you are using a plugin and not a native tag
- you can trace the plugin to its author without having to look into its code
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
Pull request sent for the parser optimisations (not the prefix handling).
Offline
Re: Making plugins first-class citizens
ruud wrote #290564:
Pull request sent for the parser optimisations (not the prefix handling).
Terrific, huge thanks! But shouldn’t you optimize splat() function too?
It’s a shame most users won’t notice the result of this work (though their server will). If we return to short tags, what about <abc@plug /> syntax? An additional benefit would be the possibility of txp-prefixed “core” plugins: <txp@core_plug /> .
Offline
Re: Making plugins first-class citizens
etc wrote #290567:
Terrific, huge thanks! But shouldn’t you optimize
splat()function too?
I’m not sure if it’s worth doing that. If I loop 10.000 times, I get these results for an attribute $text that consists of 3 spaces:
- original: 13ms (surprisingly fast, given the length of the regex)
- empty(trim($text): 7ms
- strlen(text) < 4: 6ms
In other words, you’d save 6ms on 10.000 tags without attributes, but lose 6ms on 10.000 tags that do have attributes. I don’t know how many tags are typically parsed per page, but let’s say it’s 100 tags, then you’d gain at most 0.06ms and only if none of the tags have attributes.
If we return to short tags, what about <abc@plug /> syntax?
Given the normal meaning of the ‘at’ sign, having abc@function is in the wrong order (function@abc would make more sense). Let’s see which options we have:
<abc;function>
<abc:function>
<abc::function>
<abc~function>
<abc!function>
<abc@function>
<abc#function>
<abc$function>
<abc%function>
<abc^function>
<abc&function>
<abc*function>
<abc|function>
<abc+function>
<abc=function>
<abc?function>
<abc,function>
<abc.function>
<abc-function>
<abc_function>If you want to be able to optimize the parser, it would have to be a separator that doesn’t occur often in natural text / HTML.
If <abc:function> is ruled out, I’d go for <abc::function>.
Offline
Re: Making plugins first-class citizens
ruud wrote #290589:
I’m not sure if it’s worth doing that. If I loop 10.000 times, I get these results for an attribute $text that consists of 3 spaces:
- original: 13ms (surprisingly fast, given the length of the regex)
- empty(trim($text): 7ms
- strlen(text) < 4: 6ms
In other words, you’d save 6ms on 10.000 tags without attributes, but lose 6ms on 10.000 tags that do have attributes. I don’t know how many tags are typically parsed per page, but let’s say it’s 100 tags, then you’d gain at most 0.06ms and only if none of the tags have attributes.
Not sure we are speaking about the same optimization, sorry. splat() is called by processTags() on each iteration, so I meant caching preg_match_all result, something like that:
function splat($text)
{
static $stack = array();
$atts = array();
$hash = sha1($text);
if(isset($stack[$hash])) $atts = $stack[$hash];
else { /* fill and store $atts array */}
foreach($atts as &$attr) if(strpos($attr, '<txp:') !== false) $attr = parse($attr['val']);
return $atts;
}You probably won’t save much time with this, but it’s consistent with other optimizations.
Edit: <abc::function /> scheme is my preferred too.
Last edited by etc (2015-05-09 11:44:26)
Offline