This is basically the answer that everybody gives, however this is just not an option. (Which also makes this a very frustrating question to ask, as many people insist that you are just simply wrong for asking it without any understanding of our requirements.)
We have data sets that we cannot pull into memory, we have to do an RPC to get the data. The template is the only entity that knows exactly which data from the data set is needed. Pre-computing the data would completely defeat the purpose of using templates at all. For reference, I'm running on an embedded system with a limited amount of RAM and need to pull values from a database on flash storage. Which values do I need? The template knows. I don't have enough RAM to pull in all of the values. Additionally, some of the values come from real-time data collected over i2c, which is very slow and expensive operation. I can't just go pull all of the values. -- Michael On Wednesday, May 31, 2017 at 9:06:21 AM UTC-5, Tom Limoncelli wrote: > > There may be a solution to the problem you have, but let me recommend you > take a different approach and pre-compute RPC calls before calling the > template. It will make your code easier to test and debug. Personally, > the functions my templates call tend to be self-contained or zero > dependencies: formatting a string, selecting items in a list, etc. It works > better for me... YMMV. > > Changing your code this way may require duplicating a loop outside the > template and inside the template. For example, if the RPC call is made in a > template loop, you'll then need a related loop to precompute the answers > prior to the template. A change to the template will require a change to > the code that precomputes values. That's a maintenance burden. However > there may be situations where you can move the RPC-calling functions to a > subtemplate > <https://stackoverflow.com/questions/11467731/is-it-possible-to-have-nested-templates-in-go-using-the-standard-library-googl> > and > isolate the precompute code to be near there, to make maintenance easier. > > Best, > Tom > > > On Wed, May 31, 2017 at 1:28 AM, Michael Brown <michael...@gmail.com > <javascript:>> wrote: > >> I am designing a system that will heavily use text/template processing >> and I've run into one issue that is going to be a show stopper for me if I >> can't figure out a way around it. >> >> Execute() on a template will run all of the functions in the template >> serially. >> >> For example, when you run the code below, you can see it output "slept" >> once every second until it completes after 3 seconds. In this example, the >> sleep is simulating an RPC call to another process that may take some >> considerable time (few tenths of a second), but there will be a large >> number of these calls that could all theoretically run in parallel (ie. >> there are no data dependencies between them). I'd really like to know a way >> that I could have the templating engine run all of the functions at once >> and collect the output, ie. in the example below, the entire program should >> run in 1 second. >> >> package main >> >> >> import ( >> >> "text/template" >> >> "os" >> >> "time" >> >> ) >> >> >> var funcMap = template.FuncMap { >> >> "sleep": func() string { time.Sleep(1 * time.Second); return "slept" >> }, >> >> } >> >> >> func main() { >> >> tmpl, _ := template.New("test").Funcs(funcMap).Parse("{{sleep}} >> {{sleep}} {{sleep}}") >> >> tmpl.Execute(os.Stdout, nil) >> >> } >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Email: t...@whatexit.org <javascript:> Work: > tlimonce...@stackoverflow.com > Blog: http://EverythingSysadmin.com > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
