[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Last technical issue for 1.5-rc1 -- RFC
- Subject: Last technical issue for 1.5-rc1 -- RFC
- From: Erik Huelsmann <..hidden..>
- Date: Thu, 5 May 2016 10:17:20 +0200
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 .
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.
**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).
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.
 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.
Robust and Flexible. No vendor lock-in.
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
Ledger-smb-devel mailing list