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.
**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.
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.
------------------------------------------------------------------------------
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!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
