Quote:
Originally Posted by chaley
Hmmm... interesting. I can see how to do it using the same syntax as function definition, something like this
|
I was thinking about a completely seprate mode that would start with a keyword like python: as opposed to program:. But your idea has its merits because it allows mixing both modes.
Quote:
Originally Posted by chaley
The biggest problem is avoiding recompiling the function every time the template is used. I think I can deal with the majority of cases by adding to the existing template cache mechanism used for composite columns and template searches. In the db, cache.py and search.py keep a copy of the parsed template, reusing it as required. I could add the python functions there.
|
Yes, I thought it would be cached somewhere.
Quote:
Originally Posted by chaley
The next biggest problem is the db isn't always accessible to the python code. It is available for any mi created by cache.py.get_metadata(). In some cases the mi is built by hand or from a json dict, such as the templates in save_to_disk. These templates will fail if the python code attempts to use the db (cache.py.someting()) because mi._proxy_metadata will be None. Template functions such as book_values() have the same problem so we might be able to ignore it.
|
As long as we know exactly where it should fail, and document it properly, I don't think it would be a problem.
Quote:
Originally Posted by chaley
I think the above would more useful if it integrated with the proposed dict_() functions. The python code could set or get values from the internal support dictionary passed as a parameter. Any dict_() call template code would operate on the same dict, permitting the two to interact.
|
I think this would be more clear if illustrated with pseudo code.
Also, feedback from others would help crystallize this whole thing even more.