Forum OpenACS Development: Fix Theming to work with OpenACS

Collapse
Posted by Dave Bauer on
The theming support currently only works in dotlrn.

This seems like it should be fixed :)

I looked around and here is how it works so far

dotlrn_site_templates
defines master template for pages under /dotlrn
defines portal_element_theme to use

The site template pages actually set a bunch of parameters for the main dotlrn package instance of what theme_id to use for new portals for users and communities.

portal_element_themes
defines location of theme files

portal layouts
defines location of files for content layout within the portal
does not seem to be tied to portal_element_themes or dotlrn_site_templates

So, basically to make this work for openacs we need a way to define the site wide master template to use the templates from the theme.

From here it looks like if we want to use themes without portals we need a table to choose the theme. Seems like this should be reusable across openacs and dotlrn.

So dotlrn_site_templates table sets the default master and theme_id for the dotlrn main package. We can imagine this behaves similarly to acs-subsite. So if we make the dotlrn package stand in for acs-subsite (code exists for this already, just needs to be activated) we can map a theme to the dotlrn instance in the same way we would like to map a theme to a subsite.

It looks like a theme really has two parts
1) master template
2) portal layouts

If you at using subsite without portals you can ignore the portal layouts but the rest of the theme should work. It is already possible to use the portal layout box css outside of a portal. (probably we should circle back around and make this consistent).

I'd really like to make this work.

Once we have it working I think we should define what a theme contains. I think we should have a theme-default that ships with OpenACS (could be zen) that contains all static resources. This includes all icons, logos, css, etc. So acs-subsite/www/resources would disappear. We'll have to figure out how to fetch files for the subsite resources from the theme efficiently.

I just wanted to open up this discussion. Probably won't happen for 5.4 (due this fall) but we should think about it and start working on it for the next release after that.

Collapse
Posted by Malte Sussdorff on
Let's just say I wholeheartedly agree with what you say and the approach of taking what exists in .LRN and make it available in OpenACS Proper seems like a good way to go. This would mean (though) in my opinion that the portal layouts configuration should be part of new-portal, though we should define the CSS in the master template of the theme. This would mean a theme contains all the information, including the portal one, but the functionality for portals and changing themes on portals is not part of acs-subsite (which is the place to choose the theme from).

It is important (in my opinion) that you are able to provide a full path to a theme. I am not sure we should make each theme a new package as we do at the moment. Maybe we could have a themes package which becomes a placeholder for all the themes that people provide back to OpenACS? As long as you can specify the theme by full path, that should be fine.

How does this effect the whole discussion how many masters we need and where to get them from? I think we should solve this in one go. While at it, a theme should also support the default list and form templates. I know that you should not have to use them anymore and default to CSS, but unless there is some guidelines which explain how to do that, most users might shy away from the exercise.

Would themes also take into account the group-master in the sense that using group-master is a theme? Or is a theme one level above, therefore, if you use group-master, dotlrn-master or default-master does not matter, the theme deals with the colors, layouts and such things irrespectively of the underlying master?

Collapse
Posted by Hamilton Chua on
Malte,

I think a possible solution is to use Lee Denison's template head code.

Dave B. encouraged me to have a look at it.

I did and ajaxhelper now uses template::head to dynamically load style sheets and javascript sources that a particular helper needs.

It's documented here ...
http://www.openacs.org/xowiki/templatehead

Dave and I was just discussing about committing the template::head code to CVS HEAD earlier this week.

Ham

Collapse
Posted by Dave Bauer on
Malte,

I think we'll still need list and form templates.

I think they should live in the theme.

We'll have to fix that, since they all must be in acs-templating now.