I am using [site_node_closest_ancestor_package acs-subsite] in the Curriculum package, and then [site_node_apm_integration::get_child_package_id curriculum] in order to retreive the package_id of the single curriculum instance that is allowed in any given subsite ...

In dotLRN, we want to be able to, and are indeed able to, mount one package instance in each club, class, etc. - which proves (I think!) that each class, club, etc is a separate subsite. So far so good...

However, for some reason, clubs and classes aren't "pure" subsites; they are packages with the package-key "dotlrn". Hence [site_node_closest_ancestor_package acs-subsite] won't work as expected. In a default dotLRN 1.0.1 install, it will return the package_id of the "Main subsite", when in fact what I'd like it to return is the package_id of the club or class or whatever subsite the request was issued under. The behaviour will be the expected one if I replace the "acs-subsite" argument with "dotlrn" but the proc will then stop working outside dotLRN!

I suppose my question boils down to how this incompatibility might be solved. By introducing a new package parameter, perhaps? Hmm...


/Ola

A list of package_keys sounds fine, to me.

I noticed there's a new proc, "site_node::closest_ancestor_package". Should I go ahead and modify that one instead, and mark the old one as deprecated? If so, while I'm at it, I think I should make the new proc's -url parameter default to [ad_conn url] instead of "/", no?

(I've reported that bug here: http://openacs.org/bugtracker/openacs/bug?bug%5fnumber=580)

Besides changing "site_node_closest_ancestor_package" to iterate a list of package_keys, the code I'm writing will have to check whether .LRN is installed or not, and if it is pass the "dotlrn" key in addition to "acs-subsite" (which the list will always contain). If I don't do that check but instead hard code the two keys, and dotlrn's not installed, things go south since the system doesn't recognize the key "dotlrn"...

Also, the list must look like this: [list dotlrn acs-subsite], i.e., "dotlrn" as the first element, otherwise it will detect the main subsite before it detects the dotlrn instance the curriculum is under.

So, If you agree that I should check for the existence of .LRN, then another known problem arises, namely that of checking if a package is installed. I brought this up before in this thread: http://openacs.org/forums/message-view?message_id=105027

The use of "apm_package_installed_p" was suggested, but since it is being cached the answer from that proc is not entirely reliable; the server will need a restart if a package has been uninstalled...

Do you have any thoughts on how to proceed?