Re: Sigma template

Hi! Sergey Vasilyev wrote:

1. Function callbacks are performed every time each block is parsed. This includes "empty" blocks. I don't think this is the way it should be. For example, consider the following template: <table> <!-- BEGIN table_cell -->

    func_startCell({col_num}){table_item}func_endCell({col_num})

<!-- END table_cell --> func_endRow({col_num}) </table> Functions func_startCell and func_endCell keep track of all calls and return the tags for opening/closing <tr>'s and <td>'s depending on the number of columns {col_num}. Function func_endRow should close the <tr> tag if needed. Now if we try to parse this, we will run into a small problem: func_endRow won't work as expected. The reason for this is that when the global block gets parsed it will again execute func_startCell and func_endCell from the inner table_cell block (even though this block will be considered empty) before it executes func_endRow.

This makes sense. I'll see whether processing callbacks in non-empty blocks only will break anything and if not will maybe change it as you suggest. I think it is a matter of moving the "perform callbacks" (line 611) and "subsitute variables" (line 633) blocks into the "check whether is empty" (line 639) block in parse(). You can try doing this yourself and looking whether 1) unit tests pass and package examples behave as expected 2) your problem is fixed

2. If there are two identical calls to the same function with the same parameters within the same block, the result from the first call is saved and used for the second call. This might seem like a good idea, however these two calls might return different results - for example, toggling the colors of table rows. There is an easy way to bypass this - just introduce a dummy parameter to make these calls look different. However this is a little cumbersome. It would be much better to be able to either turn on/off this behavior, or maybe instead be able to save results from function calls into local variables for later use, e.g. ...{aaa='blah-blah-blah':function}.....{aaa} This doesn't look like it is very difficult to implement.

This behaviour is by design. I do not want to change it and do not want to add Smarty-like syntax for assigning the variables: dummy parameter is way easier to add than the convoluted construct you propose.