darnocian

I tried to provide flexibility in many places. https://github.com/sempare/sempare-delphi-template-engine/blob/master/docs/configuration.md begin var ctx := Template.Context; ctx.StartToken := '{{'; ctx.EndToken := '}}'; Assert.IsEqual('hello', Template.Eval(ctx, '{{ if true }}hello{{else}}bye{{end}}')); end; There is a restriction however. Must be 2 characters in length. It will work as long as it doesn't conflict with any of the other tokens (no validation is done on this however, so you just need to check if you do override) There is also a global override where you can set GDefaultOpenTag and GDefaultCloseTag. These are defined in Sempare.Template.Context.pas. Once set, you don't have to explicitly create a context if you don't need one.

Hi, Just a small announcement that a new version (v1.4.0) has been released. Changes: NEW: Context.StreamWriterProvider which allows greater flexibility in providing custom overrides to the StreamWriter NEW: Support for statement start and end tokens allowing for content to be swallowed (useful when statements are multi line) NEW: Added helper variables and functions for spaces, newlines, tabs, chr() and ord() FIX: Issue with custom text writer that supported a few options regarding newlines, but had a bug when it came to carriage returns. (not noticeable under html) FIX: Fixed a double free bug in a ParseFile helper. UPDATE: Documentation updates Context.StreamWriterProvider flexibility var ctx := Template.Context(); ctx.StreamWriterProvider := function(const AStream: TStream; AContext: ITemplateContext): TStreamWriter begin result := TStreamWriter.Create(AStream); end; The above is an example of how the override can be done on a per context basis. There is a GDefaultStreamProvider which is used when the context is initially created which can be used for global initialisation. Allow swallowing of content between start and end statement tokens Say you have a scenario like: <% for i := 1 to 5 %> <% i %> <% end %> What you may notice is that there are many newlines that appear something like: 1 2 3 4 5 Now consider the following: <% for i := 1 to 5 |> <% i %> <| end %> In this scenario, all normal output between |> and <| are ignored, except statements such as explicit print() or variable references will work as normal. Why? It just means that the template becomes responsible for any indenting and newlines within the end (|>) and start ( <|) tokens. --- If you have any feature requests or bug reports, please raise them on https://github.com/sempare/sempare-delphi-template-engine/issues

A fix is now in the dev branch with some additional tests and a way to also change the StreamWriter if required. Will look at new tagged release next week or so. (with the fix in the dev branch, the the Context workaround above would be invalidated)

@mvanrijnen Just looking at the bug you highlighted, there is also an alternative workaround by setting the IContext.NewLine = #$A. procedure TTestTemplate.TestNewLine; type TRec = record Value: string; description: string; end; var r: TRec; s: string; ctx: ITemplateContext; begin ctx := Template.Context(); ctx.newline := #10; r.Value := 'a value'; r.description := 'some desc'; s := Template.Eval(ctx, 'Value: <% value %>'#$D#$A'Description: <% description %>', r); Assert.AreEqual('Value: a value'#$D#$A'Description: some desc', s); end; I have a custom StreamWriter that allows for stripping repeated whitespace and new lines. I'll look into also providing a way to override that better.

Yes. Use in a multi threaded environment should be totally fine. I've even used it to serve html on an indy server. There is locking used internally when accessing some internally managed collections as required. You can load templates on the fly and the locks ensure the state of the structures don't get corrupted. You can load/parse templates upfront or on demand safely. There is no global/shared state that should cause any issues. There are a few different Template.Eval() overrides which allow you to use the templates that have been pre-parsed, or you can just reprocess a textual representation as required. When evaluation takes place, the state is totally independent of any other execution on other threads.

I just looked at the tests... mostly testing with #$A. 😉 But made a test to replicate the issue.

Thanks for the report. Could you please raise the issues on https://github.com/sempare/sempare-delphi-template-engine/issues I'll check it out. A double #$D would not be ideal. The #$A is more easily noticeable, but most of the stuff I used was HTML where this would have been ignored.

Performance wise 100% agree with you David. It was more an example to check it out initialisation in case that was an issue.

I realise this is an old post... The other thing - usually with COM, you need to CoInitialize() in each thread, and if you are a nice citizen, CoUninitialize(). To coordinate shutdown, you may also want to look at TCountdownEvent from System.SyncObjs. TCountdownEvent waits for a counter to reach zero. A signal in a thread would trigger the countdown. Could do something like (sorry, I automatically referenced TTask.Run rather than Parallel.Async) // This is pseudocode, so might not be 100% accurate with params var event := TCountdownEvent.Create(); event.AddCount(length(workList)); for var work in workList do begin TTask.Run(procedure begin CoInitialize(); try process(work); finally CoUninitalize(); event.signal(); end; end; end; event.WaitFor(INFINITE); With the above code, if run from a UI would still block, so that should also be threaded if the UI is meant to remain responsive.

A new version (v1.3.1) is available on github with bug fixes (https://github.com/sempare/sempare-delphi-template-engine) Hope to have the update in getit shortly too.

It is now available via GetIt as well

FYI. I recall that you can reference the base ptr on the underlying PyArray. Definitely coming from unmanaged code, you want to try avoid copying if you can. C++ Boost does it quite nicely actually. I last bridged the c++ / python route a number of years ago, so with delphi it will be possible. https://www.boost.org/doc/libs/1_64_0/libs/python/doc/html/numpy/tutorial/ndarray.html https://github.com/boostorg/python/blob/develop/src/numpy/ndarray.cpp inside there is from_data_impl which I think should also be an interesting reference.

I was very disappointed too. It seems like they are trying to force people to upgrade. Requesting pricing won't help - I've done it twice already - they simply state it is no longer available. I appreciate it takes some time to manage packages, but is it really worth upsetting users that have been buying the product? Anyways, alternatives are available, even other programming environments were connecting to a database is not 'an enterprise feature' and is free...