Re: Last technical issue for 1.5-rc1 -- RFC

On Thu, May 5, 2016 at 10:17 AM, Erik Huelsmann <..hidden..> wrote:

Hi all,

The last technical issue that we have left for 1.5-rc1 in the issue tracker is #854 (https://github.com/ledgersmb/LedgerSMB/issues/854): Included templates not loaded from the database.

Now, I think I can fix this issue - and probably reduce overall code complexity of the template processor and more, however, that would require tying our template library more strongly with Template::Toolkit (TT).

In the past, we have talked about replacing TT because it might not be fast enough. So, before I embark on tying our code deeper into TT, this is a question that begs to be answered: Do we really want to go that way?

Assuming we need a templating engine for years to come, I looked for other templating engines. This is not easy, because we have a lot vested in templates running on TT. One that stands out is Text::Xslate, because it has a mode where it accepts - according to its own docs - a lot of TT code. On closer investigation, it seems that this isn't true, because we use alternate delimiters "<?lsmb" and "?>" instead of TT's default "[%" and "%]". So, this advantage doesn't seem to apply. Text::Xslate is said to be very fast though -- one of the properties we are to be looking for [1][2].

Then again, if we're going to be using Dojo widgets more and more, we'll be able to use the Dojo template engine to build the page client side. If that's the case, then do we - long term - still need a (blazingly fast) server side template engine? (There's an issue about this with a question from me regarding our payments screen: https://github.com/ledgersmb/LedgerSMB/issues/1077 ).

My question comes from the fact that I'd expect us to use dynamic page techniques that dojo's dgrid employs to do scrolling without building the full page. Instead, it builds only the visible part of the page. All this based on web services which can serve result ranges.

My thinking on this is that I think this is exactly the right question. My thinking is that the logical strategic direction is for us to move in the direction of more dojo widgets, more services, and hence more client-side templates and less server-side templates.

This means that we still need templates for generating HTML/PDF/etc docs where we need to do this (financial statements, invoices, etc) but not for general use of the system. I don't see TT as having a major performance problem at that point.

**Note** that the use of a high-performance templating engine serves a different purpose in our application than the templating engine which needs to support loading INCLUDEs from the database: the former is to handle our UI generation, the latter supports the generation of "document output" (invoices, packing lists, etc).

agreed

We might decide that it's fine to stick with TT for the purpose of our "document output" while we want to keep the option open to switch to another template processor for our UI generation. If that's the decision we reach, then I guess it's fine for me to start using more of TT's features with our template engine to solve issue #854.

Comments?

[1] https://metacpan.org/pod/Text::Xslate#High-performance

[2] I'm not sure if the comparison uses TT's feature of "compiled templates" which LedgerSMB can use -- this basically eliminates the need to parse a template more than once.

--

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more