Forum OpenACS Development: Subsite package keys: 'acs-subsite' vs. 'dotlrn' ?

1: Subsite package keys: 'acs-subsite' vs. 'dotlrn' ?

Posted by Ola Hansson on 06/12/03 10:05 PM

Hi,

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

2: Re: Subsite package keys: 'acs-subsite' vs. 'dotlrn' ? (response to 1)

Posted by Don Baccus on 06/12/03 11:30 PM

Well ... no these aren't subsites, they're instances of dotlrn (as you point out) and dotlrn implements a lot of subsite-like capability. In fact, my original hope was that Open Force would extend or improve acs-subsite rather than write a new package to provide this piece of .LRN functionality.

As to how to solve the problem ... I don't have a solution at the moment. One possibility would be to have site_node_closest_ancestor_package take a list of package keys rather than a string - "give me the closest ancestor package in this set of keys". This might actually be useful in other circumstances, and due to the Tcl string->list conversion rules should be transparent to current code.

You'd then pass [list acs-subsite dotlrn] ...

This is gross of course because curriculum shouldn't have to know about dotlrn's existence but I can't think of a clean way offhand to do what you want (maybe someone else will)

3: Re: Subsite package keys: 'acs-subsite' vs. 'dotlrn' ? (response to 1)

Posted by Ola Hansson on 06/13/03 08:19 AM

Thanks, Don!

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?

4: Re: Subsite package keys: 'acs-subsite' vs. 'dotlrn' ? (response to 1)

Posted by Peter Marklund on 06/13/03 11:47 AM

Ola,
defaulting to [ad_conn url] seems like a good idea to me and remember to check with [ad_conn isconnected] if there is a connection. I didn't deprecete the old proc since it has ever so slightly different arguments and semantics, the details of which I forget. Maybe we should still deprecate it though in the interest of focusing our efforts on one proc.

5: Re: Subsite package keys: 'acs-subsite' vs. 'dotlrn' ? (response to 1)

Posted by Ola Hansson on 06/18/03 02:14 PM

I think I will stick with the older of the two procs for now as I don't get the new one to work with a package_key of "acs_subsite" (it returns "") when .LRN is installed.

(I've reported that bug here: https://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: https://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?

6: Re: Subsite package keys: 'acs-subsite' vs. 'dotlrn' ? (response to 1)

Posted by Peter Marklund on 06/18/03 02:28 PM

Ola,
I think apm_package_installed_p is reliable enough to use as it is.

7: Re: Subsite package keys: 'acs-subsite' vs. 'dotlrn' ? (response to 1)

Posted by Peter Marklund on 06/18/03 03:13 PM

Ola,
or maybe it wasn't reliable enough previously, but now it is because I added flushing of the installed_p cache upon uninstall. Thanks for pointing out this issue.

8: Re: Subsite package keys: 'acs-subsite' vs. 'dotlrn' ? (response to 1)

Posted by Ola Hansson on 06/18/03 03:45 PM

Hey, that's great!

I'll just use that to check for .LRN, then. Did you commit this to HEAD?

Thanks Peter.