Welcome Guest, Not a member yet? Register   Sign In
ClassFormerlyKnownAsTemplateParser
#1

Compared to the template engines available, I think that the CI3 TemplateParser is misnamed, as was the CI2 ActiveRecord (which became QueryBuilder in CI3). The TemplateParser has been both slammed and praised, by those who see no need for it and those who find its simplicitity handy, respectively.

For the record, I fall into the latter camp. I use the TemplateParser all the time, specifically to remove any PHP from views. It is my opinion that views are better left to web designers/developers, who may not have conventional programming skills, but who are proficient in HTML+CSS and often javascript. Not everyone will share this opnion, and that is fine.

However, I am migrating the CodeIgniter website to CI4, as my proof-of-concept/testbed app, so I will be implementing equivalent functionality. It won't be called TemplateParser - that name is not appropriate. It isn't even the same "kind" of tool that the other template engines are, though  PyroCms's Lex is similar (and they call it a template parser, not a template engine, even though it is often grouped with and compared to the engines).

It makes sense to add a bit more to our tool, for instance some simple control structures, but what we have is *not* a template engine, and it should not detract from the community discussions about them Smile

What do you think?
James Parry
Project Lead
Reply
#2

@jlp Exactly how we should interpret this?
The ideas what was mentioned by Lonnie in this issue: https://github.com/bcit-ci/CodeIgniter4/issues/139 will be discarded?

Lots of us who are using CI and CI related things in the last ten years or so have good experience and knowledge with Dwoo 1 CI and Lex parser (the foundation of these things are the same) because of the integration to the old PyroCMS (which was the de-facto CodeIgniter CMS since 2010) and to Phil's Template library and of course the simplicity of the "template language". I think this was the main reason why Lonnie picked Lex to get inspirations and this was a very good decision.
If you scrap and forget this legacy that is not a very message... If I remember correctly before CI was trasferred to BCIT you were not part of the community so you maybe not know about this at all...
Reply
#3

(This post was last modified: 07-20-2016, 01:10 AM by jlp.)

(07-20-2016, 12:52 AM)orionstar Wrote: @jlp Exactly how we should interpret this?
The ideas what was mentioned by Lonnie in this issue: https://github.com/bcit-ci/CodeIgniter4/issues/139 will be discarded?

Lots of us who are using CI and CI related things in the last ten years or so have good experience and knowledge with Dwoo 1 CI and Lex parser (the foundation of these things are the same) because of the integration to the old PyroCMS (which was the de-facto CodeIgniter CMS since 2010) and to Phil's Template library and of course the simplicity of the "template language". I think this was the main reason why Lonnie picked Lex to get inspirations and this was a very good decision.
If you scrap and forget this legacy that is not a very message... If I remember correctly before CI was trasferred to BCIT you were not part of the community so you maybe not know about this at all...

You have misunderstood ... if you check the issue, you will see that I have assigned myself to it, and will get the ball rolling.
Dwoo may have started from similar roots, but Dwoo 2.x now seems to be in the template engine grouping. I can see the relevance of Dwoo 1.x, but didn't look at it at first, since they are onto 2.x.
Lex does look super useful Smile

ps - I edited my comment in the issue, to clarify my intent.
James Parry
Project Lead
Reply
#4

(07-20-2016, 01:01 AM)jlp Wrote: You have misunderstood ... if you check the issue, you will see that I have assigned myself to it, and will get the ball rolling.
Dwoo may have started from similar roots, but Dwoo 2.x now seems to be in the template engine grouping. I can see the relevance of Dwoo 1.x, but didn't look at it at first, since they are onto 2.x.
Lex does look super useful Smile

ps - I edited my comment in the issue, to clarify my intent.

Thank you! Happy to read that. I am looking forward to try it out! Smile
Reply
#5

@jlp, I think one of the problems that always popped up with the template parser was that it could not handle multi-dimensional arrays and advanced control structures.

+1 for a Lex version.
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )
Reply
#6

(This post was last modified: 07-21-2016, 08:08 PM by prezire.)

My Laravel views seem neat (I'm biased and this is self-proclaimed) inline with View Composers http://icecream.me/a2c65e725cb52e8862972d82e317c5e4. Hope CI4 will have better and cleaner syntax.

I was also wondering if the above sample view from this screenshot will work http://icecream.me/06a69e909e5a5ea0810a141a5f52c099 taken from Jade (http://jade-lang.com). The number of lines are almost cut in half, add a view caching via terminal (php cli cache:views), and presto!
Long live CodeIgniter!
Reply
#7

I don't recommend Lex engine or a clone of it. Here are my arguments:

1. It is based on regular expressions, some of them are greedy. An engine that uses a tokenizer would be precise, controllable and faster.

2. The syntax is verbose and it has a significant limitation about calling nested functions. Sometimes arguments (tag attributes) should be in certain order, especially under the helper tag. For other tags you should memorize specific attribute names for every argument.

3. The Lex syntax that was on PyroCMS is extended in a dirty way in an attempt to deal with the syntax limitations.

4. There is complicated logic about {{ noparse }} tag.

5. It does not support well non-scalar data in some valid cases. I fixed this by using serialization internally.

6. It is likely not supported anymore. There are some bugs that I fixed alone. The newer PyroCMS dumps Lex in favor of Twig.

7. There is no automatic html-escaping by default.

8. There is no caching of compiled templates (because it works with regular expressions, again).

I have integration of Lex http://iridadesign.com/starter-public-ed...ry_param_2 , because I was asked to implement it. But I honestly advice you, don't go there.
Reply
#8

@ivantcholakov
This discussion is primarly about the funcionality. Parser vs template engine. And it will be a completly new thing not a fork of Lex or clone. I think we only need the same or a litte better functionalty then what provided by Lex at least that stands for my needs...

1. 3. 4. About the regular expressions you're right, it's a very ugly way... I think they chose it because it's the simliest way to implement the parsing. But for a simple parser we really need something more?
2. I confirm this too, it can be a pain in... But in case of CI's parser I think this can be solved.
5. I can't remember a problem with this.
6. Yes you're right, but Lex not will be used!
7. My first job would be to turn it off... HTML escaping should be incorporated but the developer should choose when he wants to use it. There should be a specific syntax for it just like in Laravel's Blade { var } vs {{ var }}
8. It's only a parser not a template engine. If we will get an output cache, then the caching should be independent because any output should be cacheable and that output can be produced by a simple view call, by the parser, return html, json etc...
Reply




Theme © iAndrew 2016 - Forum software by © MyBB