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

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.

Ok. That's clear. Then my conclusion is that I'll work to further integrate with TT for the purpose of output document generation and - for 1.6 - have UI template rendering separated (at the API level) from output document rendering. Specifically to support this difference:

**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

Ok. Then I'll start working the issue with the above in mind.

Regards,

Erik.