Use instance_eval to evaluate expressions about sablon HOT 4 CLOSED

@stadelmanma if we would break backwards compatibility we will need a very good reason to do so. It would mean that upgrading potentially means that you need to update all your templates.

To provide some context, would you mind sharing some expressions that this enables that are not possible now? Ideally this would be real-world use-cases and not constructed scenarios.

One more thing, in the beginning I deliberately kept the expression complexity low. Editing templates is not fun, you should be editing code. So instead of defining complex expressions in the template Sablons take would be to define a wrapping object with a method that does what you need. You can then easily change that method without needing to update any templates. I think in terms of maintenance this is a huge benefit.

from sablon.

@senny don't worry I'm not sold on this idea either (hence the proposed 😉 ). It came to mind as a way to make our context manipulations more powerful so I decided to jot it down, and invite any feedback.

Permitting more complex expressions would be part of a second PR that refactors our conditional and loop statements into the natural ruby syntax. i.e. paragraph:if becomes if pragraph. We would also have the benefit of leveraging the entire ruby environment implicitly without needing to manually code equivalent "sablon expressions" such each and if. Maintaining backwards compatibility in the second part is easy by using the same regular expression patterns we already use to transform the "old" syntax into the new.

Originally I thought this could be implemented without breaking backwards compatibility. However, after some testing and research it doesn't seem like that is possible and I don't think there are enough benefits to warrant the change. Especially given the tedium involved in updating those word templates.

from sablon.

Thanks for explaining this further. Having a more "natural" syntax would be nice for sure. However, my other point stands, you don't want these expressions in the template to get complex. You want the complexity in your code. Ping me if you happen to do a spike to implement this. I'd be interested in seeing the internals. I vaguely remember that there were some issues with parsing to know if it's a block or not, I can imagine that parsing real Ruby would be tricky.

from sablon.

Closing this as it isn't something that I think fits well within the original intent of sablon, which was to keep templates simple because they are a real pain to debug.

Something I want to do eventually is refactor the logic used to handle merge fields and their corresponding operations to allow easier extension by the end user (a sort of plugin type of API maybe). Perhaps depending on the flexibility added by those changes this could be implemented separately as an extension gem instead of being part of the core components.

from sablon.