Can this be extended to support expression tags in apache config?

[agrawalo]

I am not sure whether this parser can be extended to support expression tags, please comment. Something like jsp expression tags or something in these lines http://jinja.pocoo.org/

[etingof]

Expression tags that seem conceptually close to Apache config would probably be ap_expr. But these seem quite rigid in what they can do and httpd-specific.

jsp and jinja expression tags seem more functional e.g. you can even embed and eval some code there.

But what's your use-case?

[agrawalo]

Correct jsp and jinja expressions tags seems more functional to me too. I am not sure if we can embed these expression tags (jsp/jinja) in apache style configs and modify parser you wrote to understand such expression language as well.

Opinion?

[etingof]

It seems that it should be easy to parse stuff out of <> tag and just feed it to the jinja engine which would take care of the rest.

But that would not work with vanilla Apache configs that use Apache expression tags. So may be the way to go is to have configurable expression engine to support both cases - Apache and Jinja expression languages...?

[agrawalo]

Yes thats true. Configurable/pluggable expression engine should be a way forward. If we are able to do that then this library will become super powerful I guess.

Also I am not sure if jinja is the best one out there, you know of something better than jinja?

[agrawalo]

Do you have such a use-case in your application for which you created this parser?

[etingof]

No, my config files do not happen to use expression tags of any kind. But I think I could try to add those for the greater good. Or you can come up with a PR. ;-)

[etingof]

One thing I do not quite get is your use-case... Do you need this parser to actually evaluate expression tags? Or just parse/dump them untouched?

I wonder how reasonable would be to evaluate the expression tags given they tend to rely upon HTTP request runtime variables....

[agrawalo]

Do you need this parser to actually evaluate expression tags?

I guess this would be bit difficult but this can be configurable too (for some straight forward configs users can opt for an option to evaluate expressions inside the parser itself).

how reasonable would be to evaluate the expression tags given they tend to rely upon HTTP request runtime variables

It doesn't have to an HTTP request runtime variables everytime.

Evaluating expressions gives users flexibility to generate dynamic configurations with less config lines. For example users can write loops or write conditional statements. Let me know if you think otherwise.

[etingof]

Evaluating expressions gives users flexibility to generate dynamic configurations with less config lines. For example users can write loops or write conditional statements. Let me know if you think otherwise.

Hold on, are you talking about using this parser with the new projects, not related to existing Apache-like configs? Because original Apache config file syntax does not seem to support loops, just conditionals. Is that correct?

[agrawalo]

Correct. I mean this parser can be extended to support conditional statements and loops. So at the end this parser will be able to parse all the apache config files along with files having expressions from jinja/jsp/apache (basically a pluggable expression language syntax).

I am not sure why Apache Config file syntax does not support loops.

Though I am not sure whether you even intended to have such support in this library. Apologies for raising this as an issue if you feel this is out of the scope of this project.

[etingof]

BTW, the parser in its current state can parse ap_expr expression tags. Just parse and dump, not evaluate. So I added a test case in commit 779fef8

[agrawalo]

Thanks for adding the test case. I guess adding an ability to evaluate the expressions will make this more powerful.

[agrawalo]

Not sure if you would want to check https://docs.saltstack.com/en/latest/ref/renderers/