Forum OpenACS Q&A: Do *.vuh files other than index.vuh make any sense?

Collapse
1: Do *.vuh files other than index.vuh make any sense?
Posted by Tilmann Singer on 11/12/02 11:25 PM
It seems to me that a file called bla.vuh would be treated exactly the same as a file called bla.tcl by the request processor. Having a www/foo/bla.vuh would still result in a 404 for a request for e.g. www/foo/bla/somesub/url. To have all URL's beneath www/foo/bla/* processed by a .vuh file it is still necessary to set up an index.vuh at www/foo/bla/index.vuh.

The documentation at https://openacs.org/doc/openacs-4/rp-design.html does not even mention index.vuh. I wonder if I am missing something here - are the docs just wrong and need an update or what would be the purpose of a non-index .vuh?

There are also zero non-index.vuh's in the toolkit.

Collapse
2: Re: Do *.vuh files other than index.vuh make any sense? (response to 1)
Posted by Ben Adida on 11/12/02 11:32 PM
Tilmann: this seems more like a bug than anything else. foo.vuh should definitely register foo/*. In fact I was convinced that it worked this way, but I just verified that your interpretation is in fact correct. We can probably go either way on this: only allow foo/index.vuh and treat that directory as the set of all helper files that are needed to fulfill the index.vuh request. Or fix the bug and allow foo.vuh, too.

I think the latter is more consistent and allows for all to choose their preferred style of URL and file organization.

Collapse
3: Re: Do *.vuh files other than index.vuh make any sense? (response to 2)
Posted by Tilmann Singer on 11/13/02 12:32 AM
I agree that the latter would be nicer.

I think it can be tracked down to the proc rp_path_prefixes (only used in rp_filter) which returns 

/foo/bar/
/foo/
/
when given the path /foo/bar/. Changing it to return 
/foo/bar/
/foo/bar
/foo/
/foo
/
seems to do the trick. This needs some further testing though if path_info is always correct etc.
Collapse
4: Re: Do *.vuh files other than index.vuh make any sense? (response to 3)
Posted by Tilmann Singer on 11/13/02 01:09 AM
Here's a patch: https://openacs.org/bugtracker/openacs/patch?patch%5fnumber=5

Note that for index.vuh's the value of [ad_conn path_info] is always without a slash at the beginning. For a foo.vuh file it  can either be an empty string (request for /foo directly), a single slash (request for /foo/) or more, with a beginning slash, e.g. /bar/baz for the request /foo/bar/baz.

This might be unexpected because it's different from index.vuh's, but I think it is the right behaviour because otherwise it would not be possible to distinguish if /foo or /foo/ was requested.

Anybody who has the time for some more testing?