Split templates from scripts?

[martijnvg]

Templates exist to resolve placeholders in pieces of text and can only be used in indexed scripts and ingest. While scripts are used in many other places and exist to flexible execute custom logic related to the context it is running in.

Templates are integrated into the script infrastructure (mustache implements ScriptEngineService interface, Template extends from Script and all places that use templates are hardcoded to use mustache language). I think it makes sense to strip templates from the script infrastructure and let it be its own thing. For example Template should be not extend from Script, template implementations would implement TemplateEngineService and all of the template features would be accessible from a TemplateService.

The following is a list of tasks to work towards a separated TemplateService:

• Add ScriptService#compileTemplate and cut some script compilations to that method (Templates: Add compileTemplate method to ScriptService for template consumers #24280)
• Cut all script compilation to ScriptService#compileTemplate (Templates: Add compileTemplate method to ScriptService for template consumers #24280)
• Create a Template class similar to the Script class that we can use to parse templates and use that with ScriptService#compileTemplate
• Make a replacement for ScriptEngineService for templates, us it in ScriptService#compileTemplate, and make mustache implement that instead.
• Remove template specific stuff from Script and ScriptEngineService (I'm starting to get fuzzy on exactly what this is so we'll have to clarify later)

[clintongormley]

+1

[martijnvg]

Maybe all template related features/infrastructure should move to the lang-mustache module? The main reason being here that templating is hard code to use mustache anyway.

• The transport, rest actions, template query builder should move to this module.
• We should extract the templating related code from the search api and move it to a dedicated api. This api's goal is to template any search request that it receives and then delegate it to the search api.

[jdconrad]

Another +1 from me for separating templates completely from scripts using a TemplateEngineService because while some of the high level code would be duplicated, the details are quite different from parsing to execution.

[nik9000]

I talked to @jdconrad about this a while back. This is in the way or his work on "script contexts" so I'm going to work on this. "Script contexts" don't have an issues (I thought they did!) but the short description is that it'll allow scripts to be compiled for the context in which they should be run. There are lots of cool things this'll allow, one of which is that it'll let us avoid a box/unbox step in search scripts which should help to close the gap between Painless and expressions.

[nik9000]

I'm about half way through a large change that should separate the two somewhat. The goal is to provide a framework for further separation rather than accomplish all the separation that we want in one go.

[nik9000]

I took a stab at this and even with my best efforts I really wasn't able to get it small enough. So I did some brainstorming with @rjernst and @jdconrad and we decided it'd be best to have a running list of things we're going to to do complete the split. This is the list, I expect we'll add to it as we come up with more things.

Edit: Moved list to the issue description.

[rjernst]

@nik9000 I moved your list to the issue description and marked this as a meta issue. Thanks!