Separation of an applications user interface from its functionality has two main advantages:

1. Flexibility in allowing the functionality to be presented in several ways; eg. using forums as a news and announcements list.
2. Encapsulating local installation ui customisations in a separate package from the functionality providing clear separation and lower maintenance overhead.

I propose that applications should in general be split into two which would provide the advantages above:

• The first package containing the datamodel, tcl api and reusable includes in package-key/lib.
• The second containing mainly user viewable pages which form the ui but allowing small extension datamodel and tcl functionality.

The main issues with doing this that I have thought of so far 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.
• Making package installation work and the mount points make sense. Application functionality packages would not be able to rely on the fact that they are mounted and would need some way to find out where their ui is mounted.
  Proposed solution: A mapping service would relate package instances to their ui instances (maybe allowing more than one?)
• Conversely a ui package would not be able to rely on ad_conn in its current form and would need some way for getting it's functionality package.
  Proposed solution: The mapping service above.
• Upgradability
  Proposed solution: Any package converted to this approach would provide a default ui in its own www directory.

I'm working on a project which ideally would like to use the forums package with two different customised ui's so I'm looking for ways to keep the long term maintenance overhead as low as possible.

I think it's worth looking at what Jun has done with the bcms stuff since I think it follows this model. Also, this is in essence what happens when something is portalized in dotlrn (and if we make things like admin portals and cms portals it would happen there too). We end up needing page fragments that can be included in other packages and designing with this in mind from the start would be a big win.

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?

Jun,

I think that a discussion about design patterns for helper procs, whilst being totally necessary, would quickly go beyond the scope of this discussion.

A new TIP to discuss the design pattern for writing good reusable includes seems like a good idea. It would also help keep this discussion focused on separating ui from functionality. I will create this new TIP.

I like the idea of bcms-ui-base/resources (or soon to be lib), but apart from clean conceptual separation, is there a concrete advantage over simply putting them in <package-key>/lib, as it is not much of an overhead and keeps the number of seperate packages down?

don't mind my post above :)  Anyway go on with the tip.

I do like the idea of the tip.

Don,

My intention is that only reusable include chunks would live in the forum-core/lib (which, as you point out, is already the case in some packages)... I didn't mean to give the impression that datamodel or tcl api would move there as well!

.LRN does use some aspects of this approach and does benefit from pages being factored into reusable includes.  One difference though is that .LRN portlets require the original package interface to be mounted somewhere.

In many ways this TIP is about officially endorsing an approach that is already becoming the norm before I undertake a significant refactoring of forums.

Approve.

This is clearly a good idea and a direction we want to go. I also agree with Don that portlets should move in the same direction.

Once the coding is done we will definitely want to evaluate the results before we take it into to the official release.

To my thinking that now, at the concept stage and  then secondly when it is done, are the two points that OCT should be officially involved.

We should discuss, brainstorm and debate implementation choices and ideas as a community, but  we don't need to get an official OCT vote on each choice. The first time for anything is always an iterative experiment. Hopefully this will be based on BCMS and thus a second time, but that is no where close to Pind's Rule of Five.

I suggest we approve the basic idea continue this discussion outside the TIP process.

I agree that this TIP is headed in the right direction, but I have some points I would like clarified.

• Where would documentation for the singleton functionality package go?
• I believe a package-key/resources/package-key directory is still useful to the functionality package for things like supporting gifs, css, and js files.

A diagram (ascii is probably fine) of the proposed relationship and directories would be nice. In some ways, I think this TIP should be an addendum to http://openacs.org/forums/message-view?message_id=120221.

I'm encouraged by how large a group of people we have working on the various problems related to reusibility. Thanks for your work Lee.

Allowing template customizations in a controlled way that doesn't require a fork would be a great improvement. Maybe splitting up packages like you describe is a good approach to achieving this, I don't know. I think I would need a working example or a more detailed description to  have an opinion on whether this is the direction for OpenACS to move in. If you could draft the change in one package and show the advantages that would be very helpful.

A different, and more radical, approach to solving the presentation customizability problem is the work that Lars and Branimir are doing, labeled .KUL, aka data soup. Their approach is that you specify in an admin interface which object types you want, which attributes and templates they should use, and which pages your data should show up on. The idea is that you should be able to combine object types with views in a multitude of ways, i.e. show forum posts in a blog view etc.

The only pattern I see here is that the TIP forum is being used as a general discussion forum. Was this ever discussed on either of the other two more appropriate forums? Not everyone subscribes to the TIP forum, and this discussion is very far from becoming a concrete recommendation. One TIP would be changing template::util::url_to_file. This one idea may cause changes, or at least review of every public and private package. Anyway my main point is not for or against the idea, but with the use of the TIP forum before any discussion on one of the other forums. When the TIP forum is used it divides the participants into two classes: those that can approve and those who cannot.

Tilmann, I committed some changes to Forums which separated some of the more reusable ui components into includes in the lib directory.  This would make it easier to create an alternate ui for forums as a separate package - which I went on to do for my current project.  But I haven't committed anything else which explicitly supports or uses this approach.

The changes went in for 5.0, the code works the same, it's just been refactored to have most of the page fragments generated from includes in forums/lib/. So for example forum-view.adp includes /packages/forums/lib/message/threads-chunk rather than having the forum list directly generated in the .adp.

The advantage here is the portlet then can simply reuse this code rather than having to have a chunk largely copied from the regular page .adp.

The ultimate goal here is I think to further refactor forums so there would be a forums-base which had the tcl libraries, lib includes, etc, and multiple forums-ui packages which implemented front ends with possibly quite different security policy, navigation, etc.

It's not terrible to have a default interface in forums but I find having a service/application pair is easier to understand and cleaner in implementation.

Also, to be clear, the consensus on this TIP was that it was a good idea, and the refactoring of page components into includes was something we wanted to see, but changes to specific modules should be tipped individually.