When openacs packages that are not singleton, they are designed to create multiple instances of the same package, mounted in different parts of the site-map and keep their own content separate but in the same table (acs objects magic). But some times, you want to aggregate / manage data from different instances of the same package and show them all in just one place, probably checking at the same time normal read permissions, etc.
In Don's words: "right now the paradigm is "separate instances, write a summarizer portlet" but it's probably a good time to raise the issue of whether or not it's the best thing to do in .LRN, .WRK etc where you have lots of subsite-like classes and instances of stuff"
A couple of use scenarios:
1. I have wimpy-point, instantiated for each class via its portlet, but now we would like to have one wp instance mounted on /wp where you can see all the presentation that are available for public (we do have a portlet that aggregates from the classes that you belong to, but the aim is for any user: unregistered users that do not have its own portal). How to aggregate the content can be achieved relatively easy with a single script, then the question is:
a. where to locate it? (probably on /lib of the pkg)
b. how to show it? in other words, how to make the /wp instance to show that given script instead of the normal index page that just show the presentations that belong to that instance? (note that might be another potential places in the same package that might need special re-factoring to achieve this behavior)
2. The events package, we want to have 1 single place=instance (/events) to manage all the events of all the installation, while there might be events pkg instances for each single class, community or subsite. Again this case is somewhat related to the previous one where you display all the instances data in one instance and you might add data through this single instance to others instance (i.e. in /events you add an event to /dep/sub/class/events).
Maybe a cleaner solution might be, for example, create some sort of special_context_id / special_package_id that manually is set for the instance through the site-map (i.e. wide-installation-instance), then when you do the normal:
where
...
and ao.context_id = :package_id
...
It will render all the package instances information.
For the management point of view, when through the site-map the package instance is marked as wide-installation-instance, a possibility is to have a given template that will change for that single request the package_id to be passed when adding a new object or maybe cleaner is when package_instantiate_object is called, afterwards it ask you to which instance you want to add the object and then it simple updates it (like notifications does but without extra coding).
Thoughts, comments?
