search

ultraq / thymeleafjs

A basic implementation of the Thymeleaf templating engine in JavaScript
Apache License 2.0
52 stars 8 forks source link

Need an expression language, like OGNL, but in JavaScript #17

Closed ultraq closed 6 years ago

ultraq commented 6 years ago

Thymeleaf supports the use of OGNL and SpEL in templates (for non-Spring and Spring projects respectively). As tempting as it would be to use eval or new Function to evaluate expressions in attribute processors and be done with it, those methods open up huge security holes in an application, and I don't want that in this library.

So I think we're gonna need an expression language parser and execution engine, something like OGNL, but for use in JavaScript. Is there one already out there that will suffice, or will I have to write one myself?

*le-sigh*

danielfernandez commented 6 years ago

Related to this: I think as of today OGNL is bringing many more problems than else, so I'm starting to grow the idea that one of the features of thy31 should be to replace OGNL (in non-Spring scenarios) with a much smaller, much simpler (i.e. read-only to the point that it would be possible) expression language of our own.

Also, as for thymeleaf.js, I would appreciate the JS part to be as compatible syntax-wise as possible with the Java side, even if with much less functionality (in the end of the day, 99% of expressions are really, really simple).

ultraq commented 6 years ago

I'd also like the 2 expression languages to be totally compatible. I've only got dot (.) at the moment, and what I wanted which made me write this issue was the Java/JS ternary operator to be able to do some basic if/else code within expressions.

If you're thinking of dropping OGNL, then would SpringEL be the basis for what we'd be using in future, or a subset of it, or have you got something else in mind?

But yeah, the idea of having to write an expression engine... that's a lot of work! 😩

danielfernandez commented 6 years ago

If you're thinking of dropping OGNL, then would SpringEL be the basis for what we'd be using in future, or a subset of it, or have you got something else in mind?

SpringEL has deep dependencies on parts of the Spring code, so it wouldn't really make much sense to have it work separately from Spring environments. As for its syntax... actually SpringEL was built with OGNL's syntax in mind, so like 85% of their syntax is perfectly compatible (which is an advantage for us right now). That new small thing we would have for thy31 would be built from the ground up, and the idea is that its syntax would be a subset of OGNL's/SpringEL's

But yeah, the idea of having to write an expression engine... that's a lot of work!

Yes, well, also the idea of having our own parser was, and having our own escape/unescape library :D

ultraq commented 6 years ago

I've managed to build a parser and grammar that I've been using to describe the expression language parts that I've needed so far. There are still lots of gaps for all the language features I haven't encountered yet (eg: #{...} for message strings), but it seems to work for everything I've thrown at it so far.

I think what's there is good enough to be used to emulate what OGNL/SpringEL do, so I'm going to close this issue now.