Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#61 2015-03-26 18:42:10

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

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

#62 2015-03-26 19:10:50

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

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

#63 2015-03-27 09:33:39

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

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

#64 2015-04-11 21:27:12

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

Re: Making plugins first-class citizens

I have time.

Stef, should I create a patch for TXP 4.5.* or for 4.6?

Offline

#65 2015-04-11 23:02:32

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,561
Website GitHub Mastodon

Re: Making plugins first-class citizens

It should be for 4.6. Thanks.

Offline

#66 2015-04-12 22:35:08

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

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

#67 2015-04-13 13:44:51

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

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

#68 2015-04-13 14:30:01

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 9,002
Website GitHub Mastodon Twitter

Re: Making plugins first-class citizens

What I like about the prefix is

  1. you know that you are using a plugin and not a native tag
  2. 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

#69 2015-05-08 08:21:25

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

Re: Making plugins first-class citizens

Pull request sent for the parser optimisations (not the prefix handling).

Offline

#70 2015-05-08 10:04:42

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

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

#71 2015-05-08 22:50:23

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

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

#72 2015-05-09 11:42:35

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

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

Board footer

Powered by FluxBB