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

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 http://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.

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.

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.

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: http://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?