Forum OpenACS Q&A: Re: Current state of theming in OpenACS (without .LRN)

Posted by Dave Bauer on
Hmmm, you should not need an extra subsite package _under_ the main subsite unless that is a specific organization you need for your application.

For theming all you need is to apply the themes correct styles and master template in the package parameters for the main subsite. In this case there is no need to create a descendant acs-subsite package type at all.

You only need a descendant package type if you want to modify the behavior.

In either case, there isn't any reason to put your content under a second subsite.

You can either

1) Edit the parameters in the Main Subsite to point to the resources in the appropriate theme location. This has always been the case, the theme packages are just a way to encapsulate the styles and master templates in one place.

2) Edit the parameters as mentioned in #1 and convert the main subsite to a descendant package type if you want to modify the behavior of the subsite. Every web site I work on now uses this technique since the default openacs UI for acs-subsite is less than ideal, and certainly is not specific enough to meet most custom applications requirements.

Ah, yes. Ok. Thank you very much Dave.

So if you want to change the underlying queries in support of modified or changed tcl pages, converting a subsite into a descendant package type would enable you to do this. It would also allow you to export your customisations as a package so that in future you could install it on top of a default OpenACS, conveniently adding back your own customisations.

Initially I couldn't think of why you'd want to modify the behaviour of acs-subsite beyond changing the templates.

If you want to customise an existing application then I guess the best way is to create a new package, and copy the code from the one you want to modify! :-)


Posted by Dave Bauer on
For acs-subsite, basically I put the entire web site under acs-subsite.

For example, for a simple web application, I'd put all the custom user interaction under my new subsite package and extend or override any subsite features to make them simpler or more specific for my application.

OR for a complex web site, I might have many subsites all with different descendant subsite types. In this case each sub-application has its own set of users etc so using a subsite makes sense. Again everything is put into the subsite derived package.

I generally don't use any existing application packages as they all contain too many assumptions or are just a huge set of switches which makes it very difficult to meet precise demanding user requirements. I just build all new data collection forms and displays and lists using the existing core features. It is kind of hard to explain in a forum post :) This mainly is due to the extremely unique requirements of my remaining OpenACS users.