Quote:
Originally Posted by capink
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.
|
Another good point. I hadn't considered using a mechanism like python formatter functions, but created dynamically instead of statically. The code mostly exists to handle this. The dynamic function could have the same argument list as a stored python function, or perhaps a simpler one like
where db might be None. The simpler form wouldn't be usable in the EvalFormatter, used when rendering author links, identifier link rules, and tag browser collapse model templates. It also couldn't use the standard template processor, for example to use formatter functions. Like a stored python template, a synamic python template must return a string.
I would create a class instance for it. The class instances would be cached, so you could store 'stuff' as instance variables and they would persist during the cache lifetime. Templates that are cached: icon and color rules, emblems, composites, and template searches. The caches are cleared whenever something changes the database, or in the template search case on every new search.
This method avoids creating a new function syntax, which makes things easier both to implement and to document. It loses being able to intermix chaley-language templates and python-language templates, but that is probably a small loss.
I would need to make the template editor handle these, probably by removing all syntactic highlighting in "python:" mode.
Finally, this method removes the need for dict_... methods. If you know what a dict is and how to use them then you probably can write in python, or at least understand examples well enough to change them.