Forum OpenACS Q&A: Re: Current state of theming in OpenACS (without .LRN)
Finally got it.
So the conclusion to that is that for customising themes, every site should really be under a subsite node which is a child of the default 'main-site' subsite node.
Thanks for explaining.
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.
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!
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.
I noticed a couple things about openacs-default-theme...
First, in tcl/apm-callback-procs.tcl, the func in there called openacs_default_theme::install::after_install and at the ehd it sets some default settings. When I xopy the package, these settings cause the defaults to point at the copied package.
Second, openacs-default-theme (and all its copies) doesn't have a complete copy of the theme, for example blank-master and some stuff related to lists and forms.
Should I create a new theme package, which is the one copied by my script, which has all the files in the theme, and does not have the default settings when the package is installed?
Any other comments you might have on this?
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.
the script I wrote is already doing (1), and also making sure package key, pretty name and pretty plural are unique within the openacs instance. It uses an xml parser (tdom) on the .info file, and it reads that file, finds the stuff that matches the old package name (likely and currently only openacs-default-theme) and replaces it in the tdom tree, which I then write back out.
Please check it out, a reference to the git repo is in this thread somewhere. I have tested packages copied by my script, and they are working fine; the default setter in the callback being a minor inconvenience and I want input to see if other people think it's not so minor.
About (2), on blank-master, I was thinking that since it contains the outer stuff (doctype and <html ...> ... </html>) one could be motivated to alter it as newer versions of html may require different things, and I may be motivated to preserve the original.
Yes! I would love to see a theme! I am also interested in documenting the existing css classes in a refcard-like format.
Thank you very much. That is exactly the explanation I needed.
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!
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.