Forum OpenACS Improvement Proposals (TIPs): TIP #38 (Clarify/Resubmit): Modify template path resolution for ad_return_template, master tag and include tag
The new resolution order, when a template is specified, for ad_return_template, the master tag and the include tag would be:
For relative paths resolve as normal relative to the current file.
For absolute paths check the package lib directory and if nothing is found check from the server root. By default the lib dir of the current package is checked, but I propose a path of the form <package-key>://template-path would result instead in a check of the specified package's lib directory.
Any notion of what existing things would break?
Can you give concrete examples of where the current behavior is a problem?
I reasoned my way to the idea that things would only break if a current absolute path happened to coincide with a path in the packages lib directory but some grepping seemed to indicate that this was unlikely. I've been running my modification for a week or so an haven't found anything broken so far.
The current behaviour is not a problem other than if we want to encourage folks to put stuff in lib it should be as easy as possible to use them. Not needing to put /packages/<current-package>/lib seems like a good start.
I spent more than a day hacking the master tag to change the search order. There are some problems with how this tag works which will not show up on casual testing.
For one, you cannot pass in a variable to src if the variable value is the empty string. The reason is because the code just checks that '@var@' isn't empty, which it never will be.
Another problem is that the master tag is only compiled the first time it is used. Any code which executes inside the master tag is essentially static (or removed from processing) after that point, so the search order will be fixed on the first pass.
My suggestion it to compute which master tag to use in the tcl page, and pass that value in. It always has to be non-null. Maybe it can be done in the request processor or something, otherwise test for the above problems when development is complete.
I am not sure if these changes will improve that handling or not.
As it is OpenACS templates reside in the www space and can thus be directly requested by clients. Moving them into the package lib directory would solve that.
Especially if the master tag would check the package lib by default followed by the sub-site lib and global server root lib. For backwards compatability the last place to be checked would be the current location of the global default-master in <server root>/www.
Benefit: Avoid typing "/packages/<package-key>/lib"
Cost: Ambiguity, another naming scheme/convention to learn.
I don't think the benefits outweight the costs in this situation.
Is it really that bad to have to type this?
> Cost: Ambiguity, another naming scheme/convention to learn.
Ignoring the package pseudo url, which was an unpopular idea, I think this sums it up. So if people want to vote, do it based on that.