Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider granting the Context class virtual functions #32

Open
voetsjoeba opened this issue Mar 9, 2017 · 3 comments
Open

Consider granting the Context class virtual functions #32

voetsjoeba opened this issue Mar 9, 2017 · 3 comments

Comments

@voetsjoeba
Copy link

I'm currently experimenting with using the Grantlee_Templates library as a replacement for the (very) basic templating language that the Shibboleth SP project provides to render HTML error report pages:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPErrors

It's working well so far, but the issue that I'm running into is that the templating API of the Shibboleth SP project uses dynamic variable lookup, i.e. there is a TemplateParameters class with a getParameter(const char* varName) method that gets invoked at runtime to look up the desired variable from a set of different possible sources in a well-defined order.

In my replacement POC I have access to such a TemplateParameters instance, but I can't "plug it in" to the Grantlee templating system because Context::lookup is declared as non-virtual, so I have no chance of modifying how variables are looked up at runtime. If instead it were declared virtual, I could create a subclass of Context that dispatches runtime lookup of variables to the TemplateParameters instance (though only after first failing the original Context::lookup --the ability for local variables to be pushed onto the stack at runtime by various tags like for and with must stay respected).

So my question is this: would you consider virtualizing Context::lookup and related others to allow end users to customize runtime variable lookup?

@steveire
Copy link
Owner

That could be considered for a Qt 6 based Grantlee, but not before then because of binary compatibility.

However, why can't you pre-generate the context data instead of using a request-like API as you describe? Is it mostly for porting convenience?

@voetsjoeba
Copy link
Author

Because I have no reliable way of precomputing all variables. The getParameter function internally looks up variables from a number of different sources to which I have no direct access. I can look at the source code and find out and hack in manual access to those sources and replicate the final list of variables it would produce, but that requires hacking and will break as soon the implementation of getParameter changes.

@dantti
Copy link
Contributor

dantti commented Jul 16, 2017

This is also why IMHO having the same version as Qt jumping from 0.x to 5.x was a bad idea, can't a different named method be added as virtual?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants