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

Jim,

Many thanks for the detailed directions!

I will use both cases described. Case 1: Try your script to duplicate a theme package for use with a new 'test' package. Case 2: I'm modifying an existing xowiki instance with the 'extra_css' xowiki parameter, but some changes were needed in the default-theme css files. Making changes directly to the openacs released files becomes difficult to maintain between subsites and releases.

(I surmise from your answer and by testing some tcl files under the subsite admin code that subsite-convert-type no longer works in 5.7)

if you end up having to remove the package, remember that this would destroy package-specific data, and this part may involve a lot of work: somehow you should backup that data and restore it, which might involve you writing a lot of scripts to do so.

Success using the directions for both cases. Notes below.

If the package already exists, after using "manage depends and provides" to extend the package, go back to the package parameters page and use "Write an XML package specification to the packages/travlr/travlr.info file" to update the .info file.

"Subsite-convert-type" mystery solved. After a package extending subsite is created, a link for this action shows up on the "Main Site" administration page after 'Create new subsite.' There's a message key missing error (though this can be corrected using the translator mode in developer support).

To mount the package as a new subsite, just use 'Create new subsite' from Main Site admin. The form only offers the OpenACS default themes, but this can be changed later in the subsite's parameters.

Your script, new-oacs-theme-pkg.tcl, worked without problems after modification to use the local tclsh.

The only fly in the ointment: failure of the theming templates to pass the title <property> to blank-master.

foobar.tcl
----------
ad_page_contract {
    Testing
 } {

 } -properties {
    title:onevalue
    context:onelist
}

set package_id [ad_conn package_id]
set title "Testing"
set context [list $title]

foobar.adp
----------
<master>
  <property name="title">@title;noquote@</property>
  <property name="context">@context;noquote@</property>

This returns the name of the package as the title, instead of "Testing." I have an instance of xowiki mounted under this package subsite as well. The wiki pages do pass the title properly even though they use the same plain-master and blank-master templates (seen when using ADP reveal with dev support toolbar).

If you look at blank-master.{tcl,adp} you will see the actual html start tag and end tag, and see how they put any head tag stuff that is requested by the slave page author (look at the .tcl to see how it's done, and look at the ad_page_contract on that page for how to use anything there.

If you were to make a whole new system, you could write the docs as you have seen there, to describe your system. If you were to add a piece to the existing system, you can of course add docs to the ad_page_contract invocation in blank-master.

Property problem drove me batty but now solved. In the past title was passed using the property 'title.' Now many properties are passed in an array named 'doc': so doc(title), doc(title_lang), doc(type), etc.. There's another array, body, referenced in /serviceRoot/www/blank-master.tcl.

Set doc(title), and any other keys for the doc array, in the .tcl file. Then reference the array 'doc' using a pass by reference syntax in the adp file.

foobar.tcl
----------
ad_page_contract {
  Testing
} {
} -properties {
    doc
    context
}

set package_id [ad_conn package_id]
set title "foobar"
set doc(title) $title
set context [list $title]
ad_return_template

foobar.adp
----------
<master>
<property name="context">@context@</property>
<property name="&doc">doc</property>

So &doc declares a variable 'doc' which gets its reference from the symbol, doc, between the property tags. Simple for many, perhaps, but it escaped me.

I read a post in these forums by someone who said a thorny OACS configuration had him 'in tears.' Many moons earlier, while traversing some Solaris/opensolaris forum, I read a similar, stronger sentiment: compiling code in Solaris could 'drive one suicidal.' I think, perhaps, that the personalities drawn to OACS and Solaris are alike: moths irresistably drawn by the promised power of these systems and then consumed by their complexity. I can certainly empathize.