Parser

[lonnieezell]

The parser as we have it now is anemic and barely worth using. It should be expanded to something work keeping, without making it a full-blown template system. At the very least I feel it should:

• Support the current single and loop tags
• Support some form of "if/else" combo, or similar, to handle if we don't have data display error message.
• Allow parsing of PHP to be completely disabled
• Allow for custom tags, potentially like ExpressionEngine with a {plugin:method attributes} syntax.
• Allow noparse blocks
• Allow comments in template
• Allow chainable "filters" that can modify a variable before display

I think this creates enough to be useful out of the box, but allows it to be expanded as much as someone would like it to be. I think Lex can serve as great inspiration for much of this.

Open to comments and discussion, but this is my current thinking.

Development Checklist:

• Component(s)
• ... with PHPdocs
• Unit testing
• ... with >80% coverage
• User guide updated
• Classmap integration?
• Securely signed commits
• Conforms to style guide

[orionstar]

EE like custom tags + Lex would be a good combo. Huge plus for this! :)

[sv3tli0]

1 important question - Does CI 4 needs such simple Parser and what for ?

I haven't used the old parser, almost never.
I am not quite sure does CI needs such simple parser. Its only purpose duplicates the idea of Views and I don't see what is the positive side of using custom made Expressions and tags to replace normal PHP things.

My idea at the start for CI 4 was either only pure PHP to be supported or Full TE to be created.
But this parser is nothing that I will use in future..

[lonnieezell]

@sv3tli0 I've never used the old parser because it doesn't do enough to be worthwhile. At least one other person on the team uses it all of the time. I've heard of other people over the years that use it also, and try to keep PHP out of their templates, mostly for their designers sake. The discussion came up early on in the Council about whether to keep this or not and the decision was to keep. I'm of the opinion though, that if we're keeping it, it has to be useful. But - that doesn't mean it has to be useful for everyone,. Just like we're seeing with the discussion on Helpers, different people use different parts.

[orionstar]

I never used CI's Parser lib in production, but if there will be something useful, then I'll use that.
Honestly in the last few years there was only one scenario which could only be solved with a template lib: The customer had access to the views via admin, but PHP wasn't enabled because of security reasons and to avoid eval(). But I think there are other use cases...

A template parser can be used for everything what is stored in a database not just for real view files. For example: Email templates, wysiwyg page templates etc...

Or think about escaping values... if something "auto-escaping" will be implemented for example: one pair curly brace means without ecaping, double means escaping enabled, then you can shorten the prints... take a look:

vs {{ var }}

Which one is simpler and looks better, easier to read?

[sv3tli0]

@lonnieezell I understand you. Just I think that while CI doesn't have a real TE and its suggesting just a basic parser even with a 2-3 more features, this is not helpful for its users. Many developers search for TE solution in each framework they use and if they find the good CI to have just a sample parser. At the same time it look that it will stay just because it existed in the old version..
How ever sorry for discussing such things in github. Keep the good job 👍

[cosmomathieu]

+1 for something like Lex.

[jim-parry]

@cosmointeractive What am I missing? I am not familiar with a templating engine called "lex", and wikipedia says "Lex is a computer program that generates lexical analyzers ("scanners" or "lexers")." That does not sounds like the same thing.

[lonnieezell]

@jim-parry I linked it in the original description, but here you go: https://github.com/pyrocms/lex

[jim-parry]

I see it now ... the original link wasn't very distinctive & I missed it. Thanks!

[cosmomathieu]

@jim-parry Sorry for the late response. Apparently @lonnieezell already responded. Is there discussion on this in the CI forums?

[jim-parry]

There are at least two threads specifically about the "template parser"...
http://forum.codeigniter.com/thread-64376.html
http://forum.codeigniter.com/thread-62353.html

The roadmap (http://forum.codeigniter.com/thread-62615.html) expressly identifies it as part of phase 3, although I see Lonnie tagged it as part of phase 2 :-/

[jim-parry]

Agreed - the basic extensions would be useful.
The name Parser is better than ClassFormerlyKnownAsTemplateParser ... http://forum.codeigniter.com/thread-65753.html

I will start on the initial implementation, since I need it for the CI4 website.

[prezire]

A template system is needed instead of a just a parser. One that allows hierarchy of view dependencies. See how laravel does this when it comes to child and base view relationships and the order they're rendered.

[jim-parry]

Any template system will be an addon, and not core. I agree that many developers want such a thing, but there is definitely not unanimous agreement about which is "best". FuelPHP has an interesting approach.

@prezire The issue of templating is properly dealt with on the forum, not in comments for a PR for the Parser, which is not an attempt to provide or replace any templating engine, but a separate capability.

[prezire]

Cool. Thanks for clearing it up.