You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[FEATURE REQUEST]: Alternative to slots that evaluates state inputs at execution time but uses existing template engines to allow more flexibility
#66136
Open
lorengordon opened this issue
Feb 23, 2024
· 0 comments
Is your feature request related to a problem? Please describe.
I want to love the slots feature, but the current implementation is very limited and the custom parsing is prone to odd bugs. For example, as of this writing, the append feature doesn't even work as documented, because the parsing breaks when there are spaces around the ~.
Instead of trying to create some whole new language syntax and parser for slots, the idea I had was to evaluate state inputs at the point the state is executed, same as slots, but using existing templating engines. Only difference would be customizing the template syntax to distinguish between load-time templating and execution-time templating.
Describe the solution you'd like
Using jinja as an example, where we use {{ ... }} to have jinja render a template value at load time, specify an alternative syntax such as &{ ... }& that still renders the contents with jinja but does so at execution time. This would allow all Jinja syntax, functions, filters, etc within the rendering block. We would get things like "append" just as a builtin feature of the templater.
I'm not sure what the real feasibility or difficulty of this might be. But some kind of powerful and flexible run-time evaluation would be an amazing feature. Slots just are not good enough as is. Nice part of this approach is that it would be backwards-compatible with current slot syntax, and migrating would be fairly straightforward.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I want to love the slots feature, but the current implementation is very limited and the custom parsing is prone to odd bugs. For example, as of this writing, the append feature doesn't even work as documented, because the parsing breaks when there are spaces around the
~
.Instead of trying to create some whole new language syntax and parser for slots, the idea I had was to evaluate state inputs at the point the state is executed, same as slots, but using existing templating engines. Only difference would be customizing the template syntax to distinguish between load-time templating and execution-time templating.
Describe the solution you'd like
Using jinja as an example, where we use
{{ ... }}
to have jinja render a template value at load time, specify an alternative syntax such as&{ ... }&
that still renders the contents with jinja but does so at execution time. This would allow all Jinja syntax, functions, filters, etc within the rendering block. We would get things like "append" just as a builtin feature of the templater.I'm not sure what the real feasibility or difficulty of this might be. But some kind of powerful and flexible run-time evaluation would be an amazing feature. Slots just are not good enough as is. Nice part of this approach is that it would be backwards-compatible with current slot syntax, and migrating would be fairly straightforward.
The text was updated successfully, but these errors were encountered: