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

3) To create a customised/re-styled version of any OpenACS package, create a new package using the package manager that extends the application you want to customise (i.e. forums) and inherits templates from it. I thought that this would allow me to put css and adp/tcl pairs into the new package directory that would be served up in preference where they exist, but when I experimented using xowiki it didn't happen. I am therefore not clear why you'd ever want to do this either.

It can not rewrite the content of the script/link tags that xowiki puts into the package. Xowiki does a lot of templating and other things that don't quite fit into the rest of OpenACS. For example.

Your package can use a local master template for all that packages pages and add the required css/js etc in that master which then goes up to the subsite master template.

You could also just put template::head calls in the individual pages (probably xowiki is doing something like this). You'd need to extend/override the code in xowiki that is setting the path to the css file. Again, maybe there is a setting for that.

The request processor only looks in the package dependency tree for regular requests under www for tcl/adp pages. The resources filter does not (its supposed to be simple and quick and not do any database or permission hits.)

I haven't run into this issue yet myself, I usually set all the CSS at the subsite level so its consistent across all the packages under the subsite.

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.

Several things combine to form this whole theming thing:

1, subsites have these parameters that let you set where the subsite should look for the css and the whole template for every page

2. if you make your own package you want to add theming to, it can extend subsite, then you will notice it has some parameters, that look a lot like subsite parameters. Then, you would copy openacs-default-theme and point the theming parameters at your copy; editing the files inside the copy will only affect your package and its children.

3. if you want a subtree of your site to look different than the parent of that subtree, you can put a subsite there and adjust the theming parameters.

4. if you want the whole site to look different, you can either alter files in openacs-default-theme to suit, or you can make a copy of openacs-default-theme and adjust the main site's theming parameters so they point at your new theme and then edit the files in the copy.

In my case, I notice the site-node map which can tie domain names to subsites, and also notice that if I do a site that way, I might want to theme it separately, so my app extends subsite, and it has its copy of openacs-default-theme.

1. In your copy of openacs-default-theme, rename the function to something like my_new_theme::install::after_install and find/replace this function throughout the package copy. There are also some calls within this function that need to be updated before installing the package.

2. blank-master should only exist in one place for the whole instance, so its absence in the theme is by design. Your own templates combine with the blank-master. See openacs-default-theme for an example. If you want to branch the css files for lists and forms, places them in my_new_theme/www/resources/styles and add the path in your ThemeCSS theme package parameters. Alternate form templates can be placed in the theme and referred to in the formtemplate tag as style=/path/to/template.

Yes, once you have copied and updated openacs-default-theme, you will definitely want to install this new package.

If you need an example of a customised theme package, let me know.

Ryan

Thank you very much. That is exactly the explanation I needed.

Regards
Richard

Use something like http://twitter.github.com/bootstrap/ (there are plenty of other HTML5/CSS frameworks). I did this on my latest theme and its great!