Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#13 2016-04-04 20:24:11

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

Re: New parser testers needed

BTW, it’s quite easy to provide every container tag with <txp:else /> functionality, outputting the false part if, say, the (trimmed?) true part is empty:

<txp:article>
    ...article tags...
<txp:else />
    no article to show
</txp:article>

This would eliminate some <txp:if_variable value="" ... /> uses.

Offline

#14 2016-04-04 20:38:58

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

Re: New parser testers needed

Is it still possible to use else tags with non-txp prefixes: <abc::else />?

I think you can remove parse_else. It was never part of an official release.

Looks like the old functionality of EvalElse was restored. I think it could use the contents of txp_parsed instead parsing again in EvalElse, that way the users can benefit from the <abc::else /> short tags without requiring changes from plugin authors. It would also make the function less complex; instead of parsing, you’d be glueing back already parsed pieces.

Putting the parse stuff in a class with the tag registry would be nice. That might make things more efficient and we could lose a few globals.

Offline

#15 2016-04-04 20:52:05

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

Re: New parser testers needed

ruud wrote #298491:

Is it still possible to use else tags with non-txp prefixes: <abc::else />?

Not in EvalElse atm, it’s just a quick patch to test the new parser in the wild. Yes in core tags.

I think you can remove parse_else. It was never part of an official release.

Yes, if it’s used nowhere in core any more.

Looks like the old functionality of EvalElse was restored. I think it could use the contents of txp_parsed instead parsing again in EvalElse, that way the users can benefit from the <abc::else /> short tags without requiring changes from plugin authors. It would also make the function less complex; instead of parsing, you’d be glueing back already parsed pieces.

Totally agree, using txp_parsed would be more consistent. Is this a mere one-level glueing, or we need recursion?

Putting the parse stuff in a class with the tag registry would be nice. That might make things more efficient and we could lose a few globals.

Yes, but I’d leave it with you. :)

Last edited by etc (2016-04-04 20:53:08)

Offline

Board footer

Powered by FluxBB