Jon, after your comment I double checked. There is no point in contacts that depends on .LRN, so my statement of a hidden dependency is wrong. Obviously someone else (I think AlexK) cleaned it up already. Everything is wrapped in "if $dotlrn_installed_p" like my previous posting shows. I have no clue how and why Christof got to this error though.
As for super class: Taking into account that we execute code based on application_links you could *probably* write callbacks instead that do some uplevel magic using something like
foreach "callback_implementation" {
pray implementation_name is named like the target object type
call application data link like "application_data_link::get_linked -from_object_id $organization_id -to_object_type $implementation_name"
if linked_p {
execute callback_implementation
}
}
But trust me, we are using similar techniques on many pages and you do not want to go down that road.
On the other hand, the more I look into this, the more I see I could get rid of all the dependency on .LRN and get it into a custom package somehow. Just have to make sure I overwrite the existing procedures (it is only one) and use a custom /www/contact.tcl (which I probably could do the same way as we are using our own custom versions of project manager pages).
But be aware that .LRN is not the only package contacts is tightly integrated using "if installed_p" or "if linked_p" statements. Projects is one, invoices is the other. Ripping it all out should be possible before the release, but you will miss out on a lot of integration if you have the other packages installed. As nooone complained so far about these two packages the integration did not do any harm. This is especially true for all the includes in /lib that reference the other packages. Should I take them out again and move to a custom package? Not that I would do so in the next two months anyway :).
The dependency on acs-mail-lite depending on tcllib should be strengthened by requiring acs-mail-lite from OpenACS HEAD, I have to agree. As tcllib is only required in 5.3 ....
