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

Hi all,

My OpenACS work is very sporadic these days so forgive me if I'm asking an obvious question, but I can't quite work it out.

Rather than just tweaking default.css etc. I want to keep all style/theme changes in a package like the openacs-default-them is. I see some theme/css related settings in the main site parameters, but they refer to a mysterious "theming UI" which I can't find anywhere. Is it only in .LRN?

What is the current best approach to making a custom theme for an OpenACS site? Should I make a new package, duplicate the default-theme package content and manually modify the main site params, or is there a theming UI somewhere?

Thanks!

Mark,

My understanding is that you are correct. You would create a new package, use whatever already exists that is suitable as a boilerplate, and then modify to suit.

I believe that the parameters you are referring to enable you to reference your own CSS files on a per-subsite basis, without you having to make a custom package.

I also have not seen a thing specific known as a 'theming UI'. It could be referring to the user interface of the layout-manager package (and the layout-managed-subsite package which is based on it). The admin UI allows you to define the format of your pages and to place various 'includelets' as you want.

One other thing to mention, have you seen or used Xowiki? This is in fact such a flexible and powerful interface to the OpenACS content repository that there is unlikely to be a need to code anything. Certainly creating data/content entry forms paired to templates that can be fully customised with CSS and Javascript includes is possible without any coding or OpenACS customisation at all. Fragments of content can also be brought forward into pages from all over the place with very little effort.

I hope this is of some help.

Regards
Richard

Collapse
Posted by Dave Bauer on
Hi Mark,

I was supposed to write up documentation for this about 3 years ago, but I stopped doing a lot of OpenACS work and didn't have time.

Recently I upgraded and themed a few OpenACS sites.

Here is what I do.

Install OpenACS 5.7 core.

Create a new package "mysite-subsite" with the package manager. Check of "implements subsite" and go to the package dependencies to specify that this package inherits from acs-subsite.

Copy openacs-default-theme to mysite-theme and find/replace the info files, and everything you can find that references openacs-default-theme. This should be automated, but it's not yet.

Ok go ahead and install those two packages, and go to mysite/admin/ and click Convert to dependent subsite type and choose your new subsite type.

Now go to the subsite parameters and change all of them to refer to your new theme package instead of openacs-default-theme.

Now you can put all your theme related code in mysite-theme and any other custom code into mysite-subsite.

This makes it VERY easy to customize the home page, or any ui elements, admin pages etc. If you don't customize a page, it'll default to the acs-subsite version. If you replace a page in mysite-subsite it'll use that one.

Now you can easily isolate all your changes in your own packages. No code needs to go under openacs/www/ or any core packages. In fact if you want to customize ANY package, create a new package of your own that inherits the templates from the Openacs core or optional package.

This basically changes everything about how you use OpenACS to make a custom web site.

Collapse
Posted by Michael Aram on
Regarding package dependencies: What is the difference between "Services Extended" and "Services Embedded"? And how does the package property "implements-subsite-p" relate to that?
Collapse
Posted by Dave Bauer on
Hi,

Extends means that the package "is" an instance of the package it extends as well as itself. It can inherit templates from the package it extends.

Embeds works slightly differently. In the package you are embedding, the scripts/templates are under package-key/embed. The embedding package then has those scripts avaiable under www/other-package-key.

Implements-subsite-p is specifically for packages that extend acs-subsite (or extend a package that extends acs-subsite, etc). This gives openacs extra information about what packages can perform an acs-subsite role. Mainly this sets the ad_conn subsite_id variable and is used in the site_node procs to find the closest subsite.

Collapse
Posted by Jim Lynch on
Dave, could you clarify for me about the info file...

You say "Copy openacs-default-theme to mysite-theme and find/replace the info files ..." and what I'm not understanding about that, is what is the goal of that? What do we want the info file to look like? When we copied the openacs-default-theme package files, what did the info file look like before change/find/replacing?

I have a chance to try this out nowish so I'm looking for a little more guidance in that particular area.

-Jim

Collapse
Posted by Jim Lynch on
When we create the theme pkg and the subsite package, should either "inherit templates"?
Collapse
Posted by Dave Bauer on
Basically you are copying a package so the .info file needs to reflect the package key for your new package.

I do not inherit templates for the theme package. The subsite derived package needs to inherit templates and needs to "extend" acs-subsite. This way you can put only the files that are different under your derived subsite package and use the default subsite templates where appropriate.

Since a theme package is just a master template and associated css, list and form templates, inheriting doesn't make sense for the theme.

Collapse
Posted by Jim Lynch on

Dave, thanks...

(aside, note to self:

so when you want to extend a package, you would go to the package manager, click on the package, and scroll down to "manage dependencies and provides", and (as of openacs-5.7) you will see four sections... it's not the first one (provides) which you can't edit anyway, it's not the second (depend-on), it's the third one (extend), count one-tuo-three) and then add the package you want to extend. In this case subsite.

Earlier, I tried to create the subsite package -depending- on subsite, that didn't work, then I tried to take the same package and add the extend, database said unique constraint, so I made a new package, -only- extended, and whizbangabbracadabbra. worked.)

I started working on the automation, and since I have no info on the future, it will only work on 5.7.

prelim:

these are the files that have "openacs-default-theme":

jim@amdlap:/web/oacs57tst/packages/openacs-default-theme$ grep -rc openacs-default-theme . | grep -v ":0$"
./www/resources/styles/default-master.css:6
./catalog/openacs-default-theme.en_US.ISO-8859-1.xml:1
./catalog/openacs-default-theme.es_ES.ISO-8859-1.xml:1
./tcl/apm-callback-procs.tcl:8
./openacs-default-theme.info:3
./lib/tabbed-master.adp:1

and these are the files whose name contains openacs-default-theme:

jim@amdlap:/web/oacs57tst/packages/openacs-default-theme$ ls -R | grep  openacs-default-theme 
openacs-default-theme.info
catalog/openacs-default-theme.en_US.ISO-8859-1.xml
catalog/openacs-default-theme.es_ES.ISO-8859-1.xml

I'll start working on the info file, and since it's xml, I'll try to use tdom to parse into something I can look at the pieces.

Progress so far: I did one by hand, and it's working.

To add specifics, after changing files containing "openacs-default-theme", I had to...

  • alter subsite params:
    • DefaultMaster
    • ThemeCSS
    • ThemeKey
  • edit (myPackage)-theme/tcl/apm-callback-procs.tcl:
    • change the name of the namespace
    • alter -key, -name, -template, -css of both calls to subsite::new_subsite_theme
    • get rid of the default parameter setters at bottom of proc

One thing I found, is you have to rename the theme specifier because they have to be unique. In openacs-default-theme, those are named default-plain and default-tabbed. After I copied the package openacs-default-theme to a-site-theme, I renamed default_plain to a_site_plain and default_tabbed to a_site_tabbed in what was originally openacs_default_theme::install::after_install() which I renamed to a_site_theme::install::after_install().

Collapse
Posted by Jim Lynch on
Hi,

I'm working on a script that makes a new openacs package which is a theme that can be applied to a subsite. I believe I'm at 60% before a bug shakedown of the script, this is after about 2 days, and so I expect maybe 2-3 more hack sessions before the script has generated its first working theme package.

In this thread, Dave Bauer refers to automation to make a theme package; this script is meant to fill that bill.

See the action:

git clone git://github.com/jwlynch/openacs-theme-create.git

-Jim

Collapse
Posted by Jim Lynch on
OK, the script seems to work now. Give it a shot... instructions are in the script near the top.

I'll add more stuff as I go. Next thing is a little report at the end to show the values for a subsite's theming parameters to use that theme.

-Jim

Collapse
Posted by Jim Lynch on
It does build a package, which won't install because the package pretty name must be unique... I'll look into that
Collapse
Posted by Jim Lynch on
(bugfix)

the way this script works is really simple... it copies a dirfull of files, renames a couple then points everything at the new package.

I didn't set the package-name and pretty-plural values, so they took their value from the package copied from, which means they won't be unique as required by a database constraint.

So this update makes sure there are unique string values in those two variables, and when testing by trying to install the generated package showed the package installed without any problems.

-Jim

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 &lt;property&gt;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.

I've read through all this very carefully but there's something I'm still not clear about.

Is it possible to create a custom theme for the default 'Main Site' instance of subsite, without having to mount another subsite?

What I mean is, the instructions seem to require that you either create a new subsite package and mount it as a new subsite, or that you uninstall, modify, and re-install a subsite that already exists. Can you do this for the default 'Main Site'?

Alternatively, should you just mount a new subsite as per Dave's instructions, and then delete the original default subsite called 'Main Site'?

Regards
Richard

Collapse
Posted by Dave Bauer on
You can theme any subsite including the main subsite by setting the theme
parameters of the subsite instance.

You can convert the main subsite into a dependent subsite package type, if
you need to modify the behavior of the subsite but not to just change the
master template and css.

Ok, after experimenting all is now clear.

In Dave's instructions there is a step in which you 'Convert' an existing subsite to a new type - the type that you have just created the package to define.

The option will appear under 'Main Site Administration' at ./admin/ once your new subsite 'type' has been installed. This would seem to be analogous to sub-classing the acs-subsite package, and once a new sub-class is installed and available, the option to change an existing subsite to be of this new type is presented.

The word 'dependent' appears in the above instructions, which confused me when initially reading through. The option to select is actually:

"Convert to Descendent Subsite type".

Descendent in this context makes more sense.

I hope this helps someone.

Regards
Richard

Thanks Dave, I posted my second message before seeing your reply, which makes things much much clearer.

Because the thread title mentions re-theming, it looked as if you had to create a 'descendent subsite type' to activate a new theme.

This makes much more sense now.

The need to customise styling and templates is obvious to me, but it would help to understand an example use case of why people might typically need to make code customisations to acs-subsite?

(On the question of language, is it 'dependent subsite' or is it 'descendent subsite' as in the message key for the 'Convert to Descendent Subsite type' option? Only words, but potentially confusing.)

Does this facility allow for encapsulated customisation of any OpenACS package that implements subsite? So if you wanted to add custom code to xowiki for example, could you create a new package that extends acs-subsite and inherits from xowiki?

Regards
Richard

I am trying to extend Xowiki as an example of encapsulating customisations of css and templates, but I cannot seem to figure this out.

I have created a new package 'Customised Xowiki', OpenACS Core = No, Singleton = No, Implements Subsite = No, Inherits Templates = Yes.

I have mounted an instance of this application, gone to 'Dependencies and Provides', added xowiki version 0.144 to Services Extended by this package. What I get as a result is a working, empty xowiki that uses the standard xowiki templates and style sheets.

I have added a new style sheet in ./www/resources/ and put a modified view-default.adp in the ./www/ of my custom package directory, but the request processor is still delivering the original xowiki template and styles. I expected the RP to fall-back to the standard xowiki files only if I had not provided replacements

What am I doing wrong?

Regards
Richard

Collapse
Posted by Dave Bauer on
Check out the URL of the css files that are used.

They most likely look like

/resources/xowiki/*.css

So in this case the request processor is looking directly under the xowiki package

In general packages should not be providing a lot of css ad it should be consistent at the site/subsite theme level.

In your case what you need to do it either

Add a new css file that loads after the xowiki css file and overrides those styles.
OR
Modify xowiki to allow somehow specifying an alternate css file (or maybe this feature is a setting already?)

Dave,

Thanks for the reply. Yes the request processor is looking at /resources/xowiki/ which I was expecting not to happen having extended the package.

Is what I did supposed to work? I mean, would it work with other packages - did I attempt the right thing?

I am still slightly foggy on exactly what should be done for each use case.

So in summary:

1) To create a new theme where you can specify your own versions of the master templates, css and adp/tcl pages, make a duplicate of openacs-default-theme, modify, point subsite parameters and go!

2) To create a descendant package that inherits from and extends acs-subsite, create a new package using the package manager according to DaveB's instructions earlier in this thread (though I'm now not clear exactly why you'd ever need or want to do this).

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.

:-(

Richard.

Collapse
Posted by Dave Bauer on
The request processor doesn't understand the last part that you have here:

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.

......aha! Which explains the use-case for option 2. So to have styles that apply to all child nodes of a subsite node, you have to extend acs-subsite, otherwise, if you only do step 1, your custom theme applies universally.

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.

Richard

Collapse
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! :-)

Regards
Richard

Collapse
Posted by Jim Lynch on
Richardm

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.

Collapse
Posted by Jim Lynch on
Dave,

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?

-Jim

Hi Jim,

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

Collapse
Posted by Jim Lynch on
Heya Ryan!

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 &lt;html ...&gt; ... &lt;/html&gt;) 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.

Thanks!

-Jim
.

Jim,

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

Regards
Richard

Collapse
Posted by Jim Lynch on
You're welcome; I wanted to go out one level and cover the material and do so in a way that would let you do whatever you wanted
Collapse
Posted by Dave Bauer on
For CSS I suggest throwing out everything except the forms and list CSS.

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!

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