You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The template engine is currently based off a parser and interpreter. This is pretty useful for many purposes especially where dynamic interpretation requirements exist. However, templates can take time to evaluate by the interpreter depending on the logic, even if it is in the order of ms, it is still suboptimal.
Once an app and templates are mature/ ready for release, some circumstances will allow for templates to be fixed. The benefit of the design, is that most of the template language constructs map onto Delphi language constructs. We can introduce a pre-processor code generation step that emits code that can be registered with the TTemplateRegistry, allowing for native compiled speed when it comes to output being generated. Even then, there can still be a fallback to interpretation if required.
This may have some implications:
<% require ('TType') %> becomes a requirement in a template so we can identify the type of data available so we can use native types. Otherwise, we need to revert to using variants which is less desirable.
max run time may become an optional feature. if you have tested your script, it could be disabled. the main implication is in loops actually in case there is some bad logic.
dev's CI or the IDE would need to call a command line app (sempare.template.nativegenerator) to generate the include file/unit.
might need to enforce a few other requirements regarding type management. e.g. ternary will need to enforce types returned from true/false evaluation to be of the same type.
comment below if interested. This may be available only to commercial supporters.
The text was updated successfully, but these errors were encountered:
The template engine is currently based off a parser and interpreter. This is pretty useful for many purposes especially where dynamic interpretation requirements exist. However, templates can take time to evaluate by the interpreter depending on the logic, even if it is in the order of ms, it is still suboptimal.
Once an app and templates are mature/ ready for release, some circumstances will allow for templates to be fixed. The benefit of the design, is that most of the template language constructs map onto Delphi language constructs. We can introduce a pre-processor code generation step that emits code that can be registered with the TTemplateRegistry, allowing for native compiled speed when it comes to output being generated. Even then, there can still be a fallback to interpretation if required.
This may have some implications:
comment below if interested. This may be available only to commercial supporters.
The text was updated successfully, but these errors were encountered: