Forum OpenACS Improvement Proposals (TIPs): TIP #38 (Clarify/Resubmit): Modify template path resolution for ad_return_template, master tag and include tag

Collapse
1: TIP #38 (Clarify/Resubmit): Modify template path resolution for ad_return_template, master tag and include tag
Posted by Lee Denison on 12/11/03 12:41 PM
I propose adding a check in a packages lib directory to the resolution of templates to make it easier to use shared includes.

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.

Collapse
2: Re: TIP #38 (Proposed): Modify template path resolution for ad_return_template, master tag and include tag (response to 1)
Posted by Jeff Davis on 12/11/03 02:39 PM
I don't like the faux uri form for explicit paths (well, mostly I object to the package key being in the "scheme" spot, it also makes writing things that walk all the adp's and pull out urls do stupid things). I would find package://<key>/path a lot less objectionable. Another alternative would be "<package_key>:path" or something like that.

Any notion of what existing things would break?

Can you give concrete examples of where the current behavior is a problem?

Collapse
3: Re: TIP #38 (Proposed): Modify template path resolution for ad_return_template, master tag and include tag (response to 2)
Posted by Lee Denison on 12/11/03 04:11 PM
I started with the idea of "<package-key>:path" and my current implementation will accept that as well.  package://<key>/path is definately more correct as a uri - I was just looking for something less verbose than /packages/<package-key>/lib/path.

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.

Collapse
4: Re: TIP #38 (Proposed): Modify template path resolution for ad_return_template, master tag and include tag (response to 1)
Posted by Tom Jackson on 12/11/03 05:36 PM

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.

Collapse
5: Re: TIP #38 (Proposed): Modify template path resolution for ad_return_template, master tag and include tag (response to 1)
Posted by Dave Bauer on 01/14/04 07:26 PM
I want to look into how this change will affect tempates published by the content repository under site-root/templates/.

I am not sure if these changes will improve that handling or not.

Collapse
6: Re: TIP #38 (Proposed): Modify template path resolution for ad_return_template, master tag and include tag (response to 5)
Posted by Bart Teeuwisse on 01/23/04 06:08 PM
Good idea Lee.

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.

/Bart

Collapse
7: Re: TIP #38 (Proposed): Modify template path resolution for ad_return_template, master tag and include tag (response to 1)
Posted by Lars Pind on 01/30/04 06:51 PM
Hm.

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?

/Lars

Collapse
8: Re: TIP #38 (Clarify/Resubmit): Modify template path resolution for ad_return_template, master tag and include tag (response to 1)
Posted by Joel Aufrecht on 01/31/04 04:48 PM
Changed TIP status to Clarify/Resubmit since it's been > 2 weeks and no OCT members voted.
Collapse
9: Re: TIP #38 (Clarify/Resubmit): Modify template path resolution for ad_return_template, master tag and include tag (response to 1)
Posted by Lee Denison on 02/06/04 11:05 AM
<blockquote> Benefit: Avoid typing "/packages/<package-key>/lib"
Cost: Ambiguity, another naming scheme/convention to learn.
</blockquote>

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.

Collapse
10: Re: TIP #38 (Clarify/Resubmit): Modify template path resolution for ad_return_template, master tag and include tag (response to 1)
Posted by Don Baccus on 02/09/04 05:01 PM
Since the template system is meant to be file, rather than URL, based, I like the current scheme which requires one to type in the file path fragment.  Seems to make the difference between URL and file more consistently obvious to me ...