Forum OpenACS Development: default, site and blank master templates

Caroline,

I wrote it.

The idea is this:

1. blank-master is the template that drives some of the basic functionality, such as form field input focus, linking in CSS stylesheets, developer-support, translator-mode, etc., that master template authors would otherwise easily mess up, or they wouldn't keep their versions up-to-date. It doesn't show anything inside the browser frame, though (apart from translator mode/developer-support stuff), leaving completee design freedom to the template designer.

2. site-master gives you the top navigation, handling things like a link back to the index page, which isn't a link when you're on the index page already; login/logout/your workspace/admin links.

3. default-master goes all the way, to include context bar, page title, etc.

4. packages/acs-subsite/www/group-master is an alternative to default-master. It still uses site-master, but it adds a set of tabs for navigation inside the subsite.

/Lars

Hi Lars,

I've implemented this on two sites now and I have some feedback.  First let me say I love the new default look and the CSS sheets.

But in terms of the masters...First the names are not good. Blank implies to me something you should fill in. However the blank master is the one you are least likely to need to change.  Maybe "setup-master"or "top-master".

Second I am tempted to recombine site-master and default-master. Perhaps this is because my use cases are different then yours.

I am roughly dividing the purpose of graphics into two categories.

Branding: Usually affects the top and bottom, logos graphics and colors (CSS) of a site.  This is currently controlled mostly in "site-master"

Information Architecture: Controls how you use the site, where and what the tabs are.  A dotLRN based site often has very different menu structure then a non-dotLRN site.  In my use cases this varies significantly from implementation to implementation but not much from subsite to subsite. Currently this is mostly controlled with the "default" or "group" master.

Currently there is a parameter to change "default-master" between subsites.  However,
in my experience/use cases changes in templates are usually done to support changes in Branding.  In other words one site is used to provide basically the same functionality to different groups within an organization or different organizations.

Most of the changes are therefore in the middle "site-master", not to "default".

Are you implementing a lot of another kind of use cases, where the branding stays the same and just the navigation switches between subsites?  I have seen this in the past but its not at all what I'm seeing these days.

Right now I'm leaning towards combining "default" and "site" master into one. I don't think we can predict which part is likely to change and which is likely to stay the same. Each layer of template adds to the learning curve and debugging time.  Maybe call this combined template "customization-master" and the other one that we don't want graphic artists touchng: "top-master".

A site with a number of different graphic designs would have more then one "customization-master" but hopefully only one "top-master". Ideally the "customization-master" has one css linked in that modifies all the previous CSS sheets and can be different for each different design.  We also need a way for the graphic artist to control what directory all the pages look for graphics in so the page graphics can match the outer design.

Can you give me a reason, why you put the template in /packages/acs-subsite/www ?

Furthermore, wouldn't it make sense to agree to *one* storage facility for *all* templates (e.g. /templates)?

Last but not least, if we do this, would it be possible to automatically load all available templates to be useable in ://admin/configure).

What do you guys think. Jeff, does this interfere with your work.

I'm a little bit annoyed of looking all over my OpenACS installation on places where I can change the look and feel of my site. Gosh, I'm not even willing to write documentation for this as it s***s so much.

From a developers perspective I agree it makes sense to put the templates into /packages/acs-subsite/lib. But I still would put them unter /lib/templates or /templates, as this is a more obvious place for the occasional developer to look into. Any package that starts with acs- and looks like core is off limits to the occasional person installing the system (I'd assume) as this is a core package and you don't fuzz with core packages (at least, that's how I behave e.g. with PHP Horde).

OTOH, it is now documented, so if someone searches for the Community Template, this thread can be found ;).

Without looking at the code (which I should probably do but you could to :) master templates have always gone in the www tree and I've always assumed that's an artifact of the implementation of the master tag in acs-templating.

I'd prefer it go into /templates (but aren't we using /lib?) ...

BTW I'm currently working on the portal system - have it running under subsites without .LRN actually - and all the .LRN portlets store their templates in /www, which is bad.  They should certainly be elsewhere (/templates or /lib whichever is right) rather than available through the http: protocol because they're meant to be included ...

I am "skinning" a bunch of 5.0 sites this month with graphic designs not specifically designed for OpenACS.

Is there any documents, code, concensous on what the final solution for skinning should look like?

Here are some of the issues I've had so far.

1. All the things you'd typically expect a graphic artist to modify need to be in the same place and near the top of the tree. i.e. graphics, headers, footers, javascript, and at least the last CSS you load.

2. When subsites have their own design they may need thier own resource graphics (arrows and such) in matching colors. How should this be done?

3. In one case the site has different mostly static sections with radically different graphic design. I am trying to decide if I want to control the graphics with ETP or use subsites with ETP under them even through I need none of the group/user mangement of the subsite.