A doubt about the Textpattern template

Myusername · 2023-06-13 23:00:42

This might sound a bit weird, but I’d like to hear from who know Textpattern well. Most template engines out there compile directly to PHP, so that in future requests, only pure PHP code is used. There are even template engines that use an “HTML-like” syntax, like the template engine in the Fat-Free Framework. My question is, is there any reason why Textpattern doesn’t follow this approach (apart from the fact that it would probably be a lot of work)? Just a design decision or limitation?

Last edited by Myusername (2023-06-13 23:02:00)

colak · 2023-06-14 04:13:08

txp has been initially created for designers and its tags were designed to resemble xhtml. At the time, templates were not plentiful and designers embraced txp for its ease. txp’s tag system is what made it known and accessible before the uniformifigation of the web.

I do not think that we should change this as even with the parsing of the tags, txp is one of the fastest CMSs out there.

phiw13 · 2023-06-14 05:52:50

<txp: /> tags are just shortcut wrappers for (sometimes complex) raw PHP code, is it not? It is not all that much different from that “Fat-Free Framework“ framework you mention, but in a much more elegant way – and a much more accessible way.

Myusername · 2023-06-14 07:07:33

phiw13 wrote #335502:

<txp: /> tags are just shortcut wrappers for (sometimes complex) raw PHP code, is it not?

That’s what I think it is, in the end, everything is tags anyway. What changes is what happens behind the scenes.

Last edited by Myusername (2023-06-14 07:09:15)

phiw13 · 2023-06-14 07:24:49

What changes is what happens behind the scenes.

In the case of Textpattern, lots and lots of optimisation, abstracting, cajoling, … and caching!
And some magic pixie dust.

Oleg would be the ace to ask about that.

colak · 2023-06-14 13:49:26

phiw13 wrote #335504:

In the case of Textpattern, lots and lots of optimisation, abstracting, cajoling, … and caching!
And some magic pixie dust.

👏👏 🎉🎉

Vienuolis · 2023-06-14 19:07:20

Separation Principle — the most important rule for the right WWW publishing. This separation principle is a key advantage of Textpattern over all other CMS. Where only CSS is separated from HTML. Whereas Textpattern CMS separates everything that is possible (and worth) separating:

TXT text from HTML hypertext (courtesy of Textile);
CSS presentation layout from HTML structure markup;
CSS from PHP;
<txp:tags /> for dynamic XSL transformations from PHP for programming code only;
articles from images, from other media files, and even from links — with their own classification;
sections from categories and from keywords;
contents from page templates and forms;
and so on (I forget more in the meantime).

The designer does not interfere with the writer, neither of them touches the software code, any error remains local — it does not destroy the whole system.

Bloke · 2023-06-14 22:38:50

Myusername wrote #335500:

Most template engines out there compile directly to PHP, so that in future requests, only pure PHP code is used.

I expect this is done for performance reasons, effectively cacheing the output. Textpattern is in the enviable position that our tag parser is already blazingly fast and we (well, Oleg mainly) continue to find ways to optimise it.

Templating systems like Mustache and its variants, such as the one used in F3, have their place. Are there things we can borrow from them? Yes, probably. But most of the syntaxes start out with noble, simple goals and eventually become behemoth and slow as more features are added or more control is added for users.

Loops are especially awkward because syntaxes vary, and looping isn’t something that is natural to those outside a programming mindset. For(each)… Next. Do… While. Loop… Until. They all come with baggage.

Textpattern uses the concept of Forms (or containers within a tag construct) to offload loop processing to discrete, reusable chunks that ‘do stuff’. And with the advent of recent advancements in the break, breakby and breakform global attributes (combined with the ‘delayed replacement operator’ <+>) there are some seriously powerful constructs that can be made with just a few lines of templating.

It’s not perfect. We’re always weighing up ease of use vs terseness vs power and making decisions on the best way to balance the three.

Conditionals are interesting. Compare F3:

<check if="{{ @page=='Home' }}">
    <false><span>Not on the homepage</span></false>
</check>

vs Txp:

<if::section not name="">
    <span>Not on the homepage</span>
</if::section>

There’s not much in it, and I love F3, but I know which I find easier to read :)

Myusername · 2023-06-15 09:08:58

Bloke wrote #335508:

There’s not much in it, and I love F3, but I know which I find easier to read :)

When it comes to readability and even power, I have no doubt that Textpattern is much better. Developing in Textpattern is simply different; it’s very easy to accomplish complex things with just a few tags and attributes. I love the Textpattern template engine, and if you ask me, there wouldn’t be many things I would change. In comparison to the F3 template engine, F3’s is quite basic. But that speaks more about syntax and maturity than the approaches of each, right? For example, is it possible to replicate the Textpattern syntax and compile directly into PHP? That would be like merging the best of both worlds, I think. Perhaps I can try doing that someday, but I’m not sure how it would be to write Textpattern functions in pure PHP.

Last edited by Myusername (2023-06-15 09:11:21)

Bloke · 2023-06-15 09:53:45

Myusername wrote #335509:

I’m not sure how it would be to write Textpattern functions in pure PHP.

The closest we have is probably Presentation>Forms>New form: name it, e.g. mega_fn:

<txp:php>
// my awesome function here
</txp:php>

Then call it via <txp::mega_fn /> :)

The first call to the Form is cached for subsequent usage in the same http request.

Textpattern CMS

Textpattern CMS support forum

#1 2023-06-13 23:00:42