Async Eco #11
Async Eco #11
Conversation
* Altered the scanner to report the block nature of code at as part of "beginCode". This meant moving the "beginCode" invocation to after the code scan, but did not change the preprocessor. It did change the scanner tests, however, since they now detect a truncated template before they report "beginCode". I changed the test inputs, but not their meaning. * All tests are passing again. * This ends the modifications necessary to the scanner, preprocessors and compiler. The only changes now are to the helper methods in the generated code.
* Passing the error (now only ever `null`) as the first parameter to the async callback. * Updated `eco` function to take addtional boolean parameter to indicate an asyc compile. * Updated `render` to accept an option third callback function, which will trigger an async compile.
* Catching exceptions thrown by the helpers when run asynchronously. * Forwarding caught exceptions to the callback method. * Safety is moot on blocks, since only inline printed code is escaped.
|
I'd begun to develop with Async Eco, took a break, and now I'm back. This code seems to be stabilizing. I'll be working with it more in the new few weeks. In the mean time, here's my current development. I've added tests for the async code. Current users of Eco are not effected by these changes. Their code will run as it always has. All existing tests pass. Asynchronicity is enabled with a compiler flag. The resulting template expects a callback as second argument. The callback receives an idomatic I had to change the scanner slightly to report the block nature of a code scan to the I made a slight change to the Note that all existing compiler test fixtures are unchanged. The compiler output for non-async code after this patch is applyed is identical. Probably need to patch the documentation as well. Seeking feedback on progress so far. Please checkout and run tests and tell me what you think. |
First, notes from the discussion on the CoffeeScript mailing list, taken from discussion earlier today on IRC.
I've decided to make async a compiler option. If the option is all, all helper blocks are called asynchronously. If it is off, the function is identical to the current Eco generated functions. This is because the helper author and the compiler invoker are almost certainly the same person, and they will know if async is necessary or not.
When async is on, the generated function takes a callback. If it is off, the generated function returns its result as it always has.
This leads to the following programming problems with async Eco:
I've come to the following decisions regarding the questions at the end of that post:
Maybe there's a way for the helper to say that it is async, instead of having to remember that in the code? (Too much complexity defeats the use case.) ~ Currently, I'm tucking an exclamation point into the directive to indicate that the call should be async. This is fiddly. The async implementation is supposed to be transparent to the template author. When I'm writing templates, I don't want to think about concurrency. The use case given for async Eco is a template system for people used to writing themes with a a template language. Telling them they forgot the
!will only lead to a painful attempt to explain to them what it is for. Thus, I've decided that there will be no extensions to the Eco directives.This decision addresses the other question as well.
Async blocks in code and no callback? You get "[ Function ]" in your blocks. Could easily detect this condition, but how to report the error? Exception? Or let it slide? ~ Instead of async being a property that is applied per block helper, it is applied to all helper blocks in a template using a complier option. This means that if the option is not present, there is no effect at all on the existing Eco templates. This means that if you generate an async method, the async method can assert that it got a callback.