Thanks Scotty, your feedback is greatly appreciated! Yes - with nested loops you simply get the datum for whichever block item raised the event, nested or not.
What I meant was that sometimes in the handler you might need datum both for the item that the handler is in and the item of the surrounding block (or even blocks).
<!-- #each row in rows -->
<tr>
<!-- #each field in row -->
<td>{{field}}<button onclick="edit">...</button></td>
<!-- /each -->
</tr>
<!-- /each -->
`edit` might need both row and field to perform the edit, and even possiby # of row and # of field.
So a richer context passed to handler might be useful.
---
Regarding not calling functions from template by design it's all good, but you might consider introducing the ability to call some functions (through html attributes prefixed with : or _) during template interpolation.
Those could be plugins of your templating system that perform some operations (like generating attribute "hidden" or not depending on boolean argument, or binding form field to view model, or binding event handler, or something else).
Those functions might benefit from knowlege of template context they were called from (for example handler binders might want to pass this context along into bound handlers, like you already do with current item and your built-in handler binding solution).
I understand that this a bit different from what you made, but by extracting all of that functionality into separate self-contained functions exposed to the user, instead keeping it as integral, internal part of your template interpolation process, you could do yourself a favor. Because people who are missing some funtionality you haven't thought of yet might implement it themselves easily. This might increase usage of your framework and contributions from users.
---
Those are just some ideas where you might go further with your templating engine while keeping it simple. I hope I communicated them clearly enough, but if not and you are interested, please ask.
Thanks Scotty, you communicated these ideas very clearly and this all makes perfect sense to me. One of my main goals with Synergy is simplicity, which in the context of this discussion would mean a lower level of configurability / customisation, so pulling that template functionality out and moving decisions on to the user would (as you say) take the design in quite a different direction. A perfectly valid direction though, and one that would doubtlessly better suit some folk more than my approach - I'd love to see you fork Synergy and implement these ideas!
scotty79|5 years ago
So a richer context passed to handler might be useful.
---
Regarding not calling functions from template by design it's all good, but you might consider introducing the ability to call some functions (through html attributes prefixed with : or _) during template interpolation.
Those could be plugins of your templating system that perform some operations (like generating attribute "hidden" or not depending on boolean argument, or binding form field to view model, or binding event handler, or something else).
Those functions might benefit from knowlege of template context they were called from (for example handler binders might want to pass this context along into bound handlers, like you already do with current item and your built-in handler binding solution).
I understand that this a bit different from what you made, but by extracting all of that functionality into separate self-contained functions exposed to the user, instead keeping it as integral, internal part of your template interpolation process, you could do yourself a favor. Because people who are missing some funtionality you haven't thought of yet might implement it themselves easily. This might increase usage of your framework and contributions from users.
---
Those are just some ideas where you might go further with your templating engine while keeping it simple. I hope I communicated them clearly enough, but if not and you are interested, please ask.
defx|5 years ago