Dave,
I had the functionality package tied to a site-nodes because I was thinking of a scenario in which several ui's pointed to the same instance of a forum; ie. the forums functionality package is not a singleton. However given, as you point out, that most of the problems I was thinking about disappear if you have the functionality package installed as a singleton and only have one ui per instance of forums, your approach seems a better one.
This also seems to be the approach taken in the bcms package although its functionality package isn't actually declared as a singleton and doesn't contain any reusable chunks for the ui packages to make use of.
The issues for using a singleton functionality package that I can think of are:
- Converting the ui of existing packages to re-usable includes according to some conventions that amount to a design pattern.
Proposed solution: This would have to be a gradual process with packages being updated as people found time.
- UI packages would have to know which apm callbacks to implement and what api calls to make in them.
Proposed solution: these would be documented and the core package would probably provide default callback implementations.
- Functionality packages would not be able to provide default ui's in their www directory so the upgrade process would be trickier.
Proposed solution: Any application package converted to this approach would become the default ui package which depends on the <package-key>-core package. All of the principal functionality would be moved to the <package-key>-core module.
Incidentally I was also thinking the reusable includes should make use of template::set_file to allow them to be used as datasource only includes... is this function kosher?
