Page engines

[dajester2013]

This PR is to add the Page Engines (formerly Template Engines) feature to Lucee. This is a pretty big feature, so I'll provide more-than-usual explanation:

Currently, the compilation of a page happens in the PageSourceImpl class. That is, a PageSource "knows" how to compile itself. This changes it up so that a page source runs itself through it's assigned page engine that in return builds the Page instance. The main benefit of this is that now, alternate templating engines can be plugged into the system, and can return Lucee Page objects from non-CFML source.

In doing this, I've also re-implemented the compilation of .cf*/.lucee files using page engines. The "request dialect" is no longer determined by the servlet/execute methods, but by the PageEngine. Because of this, I've deprecated the PageContext's executeCFML method, and merged/deprecated the CFMLServlet and LuceeServlet implementations into the LuceeRuntimeServlet. Now you need only set up one servlet. Also, you can configure .cfm files to be run through the LuceePageEngine, and it would use the Lucee dialect. The inverse is true for assigning .lucee files to the CFPageEngine. By default, the CFPageEngine is loaded and used as the default page engine for all file extensions. However, if the lucee dialect is enabled, the LuceePageEngine is loaded as the default in addition to the CFPageEngine.

Currently, page engines can only be configured in the xml config files (either server or web). In addition, security was added so that web-contexts can be prevented from loading their own page engines (/security/setting[page_engines]). Next step is to integrate into LEX packaging, so that page engines can be configured by extensions.

[bdw429s]

This looks pretty cool-- what are the current engines that can be used? Perhaps a list of possible ones too will help some people understand what this will be capable of.

[dajester2013]

The only engines packaged with this are the CFML and Lucee dialect engines. You can look at https://github.com/dajester2013/lucee-freemarker/tree/master/lucee-freemarker-plugin for an example implementation of a 3rd party template language, but keep in mind I've not pushed the changes to make it compatible with these changes (it references TemplateEngine instead of PageEngine).

Edit: I've just pushed the changes to the freemarker engine plugin to make it compatible with this branch.

[micstriit]

Sorry the delay on this, i hope you understand that adding this feature need a lot of attention. Specially because we had to solve some performance issue that was coming with multi template engine that we need to solve first. ATM we need to focus on Lucee 5.0 and 5.1. I hope we can come back to this asap.

[dajester2013]

@micstriit that's fine. just to be clear, are you saying there are performance issues that need to be addressed with the code i submitted, or is there performance issues elsewhere that need to be solved before thinking about multiple template engines?

i ask because the lucee/cfml "page engines" use the same logic for compiling and loading pages, just moved to a different class, in such a way that alternate page engines could be added in later.

[micstriit]

having multiple template engines have changed the game. you can for example include a cfm template inside a lucee template. This has made the setting "full null support" runtime depending, so within a request that setting can change all the time. our solution to handle this is not very good and slow atm. we have a optimized solution when only one template engine is used. but before we officially add a template engine we need to solve this. So it is not about your code, it is about the code in the core.

[seancorfield]

@micstriit But that consideration only applies if you have different dialects of CFML in those different template engines -- which is not core to what @dajester2013 is proposing here -- and I thought that the "different dialects of CFML" approach had been pretty thoroughly killed off by the TAG at this point, given the lack of support from LAS for marketing a "new language" alongside CFML compatibility?

[dajester2013]

@micstriit, I thought you could already include a Lucee template inside a cfm, and vice versa. I do know you can instantiate a CFC from inside a Lucee template. From the standpoint of the interpreter and it's related settings, I've not changed anything. I simply moved the logic of converting a PageSourceImpl into a Page into a separate class, which I called a PageEngine. So what was previously PageSourceImpl.loadPage(…) -> Page is now PageSourceImpl.loadPage(…) -> this.pageEngine.loadPage(this,…) -> Page.

To the developer, nothing changes with the way the cfml vs lucee dialects work. In fact, you still have to use servlet params or JVM args to enable the lucee dialect. Now, there is a slight change in how the servlet is configured, which I think is the main piece that is causing concern. I'd be glad to talk more about it here or on slack.

Also, I will concede that this needs a good bit of testing first, and I've not provided any unit tests. I'll work on some in the coming days as I have the opportunity. Thanks for the feedback.