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

Collapse
Posted by Prem Thomas on

While trying to follow these directions, I got stuck at:

  • go to mysite/admin/ and click Convert to dependent subsite type

At mysite/admin, there's a link for 'Create a new subsite' which allows one to choose the subsite package to mount, but nowhere do I see a 'Convert to dependent subsite'

Am I just getting stuck in the wording or should I be looking elsewhere? Pointers appreciated.

Collapse
Posted by Jim Lynch on

are you just now creating the package to be themed by the copy of openacs-default-theme?

If so...

  • from /acs-admin/apm, you'll see a list of packages, go below that, create new package.
  • Give it a unique: package key, pretty name, pretty plural.
  • click checkboxes: "implements subsite semantics", "inherits templates"
  • scroll down, click on "manage depends and provides"
  • the third grouping has to do with -extending- a package. Add a package which your package extends, when it drops down the list, pick subsite.
  • you're done picking packages yours extends, get back to the main package parameters, and I'll suggest that you click on "write an XML file for this package" (or words to that effect); Now you should be able to go to the Site Map and create and mount an instance of your package. Look at the site map at the entry for your package, on the right: if you see a link "parameters", that indicates success overall (and specifically that your package has picked up the parameters applicable to subsites).

If, instead, you already have the package you want to be a subsite,

  • first, follow the instructions starting from "click on "manage depends and provides"", then come back here
  • At this point, I would suggest backing up the package (just tarring up the dir will do) then completely uninstall the package from your system, then...
  • you will have to edit (your-package).info to set <implements-subsite-p> and <inherit-templates-p>, which you may find are both set to 'f', and make sure they're both set to 't'.
  • Finally, in the apm scroll down, and click "install packages", you should find your package on the list, install that package. Once this is done...
  • go to the site map, make a url, and a new instance of your package to mount onto that url, and now you have your package that acts like a subsite.

So, now you have your package acting like a subsite (and borrowing subsite's code to do so). Since you're reading here, I'll guess the reason you're doing so is in order to have a separate set of styling files that just apply to your subsite,

Collapse
Posted by Prem Thomas on

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)

Collapse
Posted by Jim Lynch on
as you can see... case 2 is rather surgical in nature. don't do it on your production server as first cut! back up! and, let us know how it goes.
Collapse
Posted by Jim Lynch on
also, a future incarnation of the script will output what value to set where on the subsite; the script might have that info, and the threads here might have some of it, in general form.

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.

Collapse
Posted by Jim Lynch on
also remember that we're talking about two vastly different packages:

one will always be a copy of openacs-default-theme,

and the other is a subsite, or package extending subsite, whose theming parameters get altered to point at the copied theme package, which you can then alter independently from the default theme.

Collapse
Posted by Prem Thomas on

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).

Collapse
Posted by Jim Lynch on
Something I just found that we should both (or everyone if you haven't already), is (yourServiceDir)/www/blank-master.tcl at the top, in the ad_page_contract in the first {} which is for page docs. I noticed your foobar page was using old-syle <property>s, so please take a look and see if it answers any of the questions you posed just above.

-Jim

Collapse
Posted by Jim Lynch on
If you look at all the master templates and figure out how they all fit together, one thing you will see is that you can actually build any system you want, as you can start by putting the doctype and the html tag, end with the html close tag and in between, you can set up any kind of parameterization and arrangement of master templates.

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.

Collapse
Posted by Jim Lynch on
Finally, I offer congratulations for your success!
Collapse
Posted by Prem Thomas on

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.

Collapse
Posted by Jim Lynch on

Sometimes people try to focus on all the levels of the code (stuff they write, stuff that gets called, the sql stuff invoked as part of it, the declarative syntax of ad_form, etc etc)... and this can produce the exact experiences you describe... and, many times you have to pay attn to more than one level while you're learning.

I'm glad you have seen and fully checked out the master templates. In particular, notice that openacs-default-theme uses the blank-master in (yourSite)/www/blank-master.* and that only some of the files that define the html that goes out, are in the theme package. I don't know the reason, Don Baccus wrote that package and may be able to shed some light.

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.
Until now, and congrats. You read it and you immediately understood, and now you can use it. Perfect. That's all that's required. "Simple for many": it's simple for the ones who wrote it, use it all the time or at minimum, read the instructions. There is every reason that you can become the one it's simple for, and, that of course will take effort, work and practice. No shortcut. Just put in the time.