By the way although many installation of PHP5/6 have XSL extension, I would tell people in the installation instructions to ensure the have it or install it, or they won’t be able to use XSLTProcessor
ext/xsl is optional. Currently, all it requires is ext/dom and ext/filter and--I think--PCRE with Unicode support. composer.json has the full dependencies.
Oops, I think I misread the previous post and I can't edit mine.
You're right, but at the same time I don't want to suggest that ext/xsl is required. Maybe I should automatically switch the default renderer to PHP if ext-xsl is not available, but then I'd need to explain that you need to set up a cache dir for it and I'm afraid that's too much noise in the instructions. I'll think about it. That's why most of the early examples use predefined bundles, because their renderer is in the bundle.
For context: s9e\TextFormatter has multiple (functionally-equivalent) renderers. By default it uses a renderer based on ext/xsl. Its advantage is that the renderer object can be serialized and unserialized with no further dependency. It uses an XSLT stylesheet that's serialized in the object; It's nice and simple. The other renderer compiles the stylesheet to a PHP class/file, like most templating engine such as Smarty or Twig. You can serialize the renderer object too, but PHP needs to have access to its class file to unserialize it. Unless you saved your configuration as a custom bundle, or you use a default bundle.
The XSLT renderer requires ext/xsl but it needs no configuration. The PHP renderer needs to be configured (you need to specify a cache dir) but it doesn't require ext/xsl. In general, I'd recommend using either a default bundle or make your own bundle configured to use the PHP renderer.
Comments
Damn, now you're making me feel bad...
By the way although many installation of PHP5/6 have XSL extension, I would tell people in the installation instructions to ensure the have it or install it, or they won’t be able to use XSLTProcessor
grep is your friend.
ext/xsl is optional. Currently, all it requires is ext/dom and ext/filter and--I think--PCRE with Unicode support. composer.json has the full dependencies.
Oops, I think I misread the previous post and I can't edit mine.
You're right, but at the same time I don't want to suggest that ext/xsl is required. Maybe I should automatically switch the default renderer to PHP if ext-xsl is not available, but then I'd need to explain that you need to set up a cache dir for it and I'm afraid that's too much noise in the instructions. I'll think about it. That's why most of the early examples use predefined bundles, because their renderer is in the bundle.
For context: s9e\TextFormatter has multiple (functionally-equivalent) renderers. By default it uses a renderer based on ext/xsl. Its advantage is that the renderer object can be serialized and unserialized with no further dependency. It uses an XSLT stylesheet that's serialized in the object; It's nice and simple. The other renderer compiles the stylesheet to a PHP class/file, like most templating engine such as Smarty or Twig. You can serialize the renderer object too, but PHP needs to have access to its class file to unserialize it. Unless you saved your configuration as a custom bundle, or you use a default bundle.
The XSLT renderer requires ext/xsl but it needs no configuration. The PHP renderer needs to be configured (you need to specify a cache dir) but it doesn't require ext/xsl. In general, I'd recommend using either a default bundle or make your own bundle configured to use the PHP renderer.