Open up engine library for Business specific extensions and dependancy injection

[glemis]

Hello, I really like what you did here as I have also built some private wrappers etc around scriban for an Engine.
I would love ot make use of your library but there is some issues with extensibility.
I don't think it is very easy to inject new Scriban delegates, Different template loaders etc.

I have been working through some ways to do this.
Check out my fork https://github.com/glemis/Textrude

Ideally I think the core Engine should be there own Nuget package.
Then the specific implementations using the core packages aka

• Console CLI
• Interactive App
• Web APIs

[NeilMacMullen]

I did actually start putting together a nuget package for the Engine component since I agree that it makes a lot of sense to be able to wrap this into other applications but "real life" got in the way ;-) I had a brief look at your fork and it certainly looks interesting. I think it's worth considering a couple of different kinds of extensibility:

1. In-app. I actually like the idea of being able to drop in extension dlls and have then automatically expose functionality without requiring recompilation of the application.
2. Engine re-use. I think this is closer to what you have in mind. I'm a bit less convinced that DI rather than more flexibility in the API is necessarily to way to go the extensability you are after (though the TemplateLoader might be a special case) but it's quite likely I'm missing some scenario you have in mind - could you spell out some of the things you want to do that are "awkward" ?

Anyway, definitely interested in taking this further - look forward to hearing from you.

[glemis]

Yea I think the TemplateLoader is the one that DI makes most sense with as most projects using a custom one probably would set up singletons with authentication to a DB or webservice to load templates. Personally that is what I am doing for a client.

I did go overboard in my example of using DI. I pushed a new change to more fork which is a more practical example.

• It still requires that the new constructors and interfaces are made which still allows for my over the top example.
• A factory lets you configure everything in 1 place for app. Can DI it so it only gets setup once.
• New change shows using a factory which technically could be made to return different Engines with differing loaders and configuration based on inputs.
  • Which for example could be used if different areas of app or different users have access to different loop limits, Deligates, etc.
• The factory was totally optional since you can continue to set everything up just like it was before my customizations.
  • Made sure all your unit tests passed and no method signitures changed so there are no breaking changes.

TemplateManager really does not need to be a interface to allow overrides if the internals are just made more extendable like you said.

• Specifically the TemplateContext should be accessable to customize. Consumers of library probably want to setup context differently.
  • Examples like StrictVariables and may want to use different LoopLimit, ObjectRecursionLimit and as we allow users to author templates but put more limits on there clients so they can't make tempaltes that are to inefficient.

Generally I would say it would be best to support no DI and DI at the same time if users want which is why I added interfaces for the major components and made them have constructors to support it.

I haven't looked hard enough yet but is there any sort of method or way to pass the project file to the Engine and have it pass back all the outputs?

• Generally my project I would like to get to the point of having unit testing that loops through all the template projects and checks they continue to parse correctly as they are html, pdfs and json payloads they use daily for publications etc. Business critical. Would not want a code change or tempalte change checked in to not be validated as a pull request gate.

[NeilMacMullen]

Are you thinking of having this kind of configurability from within the current UI? (It's tempting to then start considering ways of allowing the user to specify options via configuration dialogs etc.) I'd kind of envisaged that people who really wanted to change behaviour would write their own UI (possibly even bypassing ApplicationEngine) but I can see why you're coming at this more from a DI angle if your wanting to keep more of the existing application while getting more flexibility in policy decisions.

Which for example could be used if different areas of app or different users have access to different loop limits, Deligates, etc.

Yes, this a great example. (Though for this specifically I like the idea of opening up the api to add a WithConfiguration(Action<>) type method.

I haven't looked hard enough yet but is there any sort of method or way to pass the project file to the Engine and have it pass back all the outputs?

Are you talking specifically about texproj files (TextrudeProject.cs) ? The closest to thing to what you want is the Render method (line 430) in MainWindow.xaml.cs. (EngineInputSet is taken from the project file, then use the EngineOutputSet to figure out which outputs you want. But... perhaps this should be easier. I raised issue #31 a while back, really as a reminder that TextrudeProject should really be layered with ApplicationEngine rather than the UI variant.

Generally my project I would like to get to the point of having unit testing that loops through all the template projects

I really like this idea - are you talking about validating output or just that the template is parseable. Either way it's trickier once you consider includes and possible reliance on environment variables.