Forum OpenACS Development: Core team heads-up. Check for curriculum bar in default master committed to HEAD

This is what went into the cvs log:
"I added a check for whether the curriculum package is installed or not to the default-master. If it is installed, the (possibly empty) bar will be included. This won't fail even if there's no instance of curriculum mounted (knock wood)"

If I should undo the change, I bet I'll hear about it 😉

Also, there's now a simple demo of the curriculum package available:
http://oacs4.polyxena.net/curriculum/

Let me know if you want admin privileges on it.

/Ola

What about a little instruction in the docs of curriculum where and how to add the <include> tag for the bar?

developer-support is a bad example, agreed. One could argue that developer-support is somehow special, because it isn't a user application, but I wouldn't have it included in the default-master either.

What do others think about that?

Definitely should not be a check in the default-master for any optional package, and if it is required, you wouldn't need to check. Maybe some type of general function that you could register your desires, but how and where? Maybe a package for the content bar to allow packages register what they want.

Or, if this is a positional issue then, along Tom's line of thinking, maybe the master template could use a generic variable similar to @header_stuff@ (call it @body_start@ and @body_end@).  Kludgy, but methinks still better than including package-specific code.

Rob

* Yikes, this embarrassingly relates to a bug which was assigned to me ages ago and for which Vinod has kindly provided a patch:
https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=68

http://cvsbook.red-bean.com/cvsbook.html#CVS_keeps_changing_file_permissions__why_does_it_do_that_

Then, a package parameter, say ShowToolbarsP, in acs-templating or acs-kernel could be used to denoted whether to display toolbars or not. A simple extension to default-master would be required in that case, i.e. if the ShowToolbarsP switch is on, then forall TPEs that match "default-master", display the corresponding toolbar. Other toolbars that I can think of are for i18n, ecommerce, etc.

Now, suppose that you need to display a toolbar (not necessarily for curriculum) in all templates of a special type, say that you want to display a user's recent history of product views in templates that are related to the ecommerce package, then you could say assign a TPE of ec-* to your toolbar and the ecommerce package would have a template that requests toolbars with "ec-special1" or "ec-special2" and so on.

The toolbars should be either read-only or both read and write (one further package parameter could be used to denote the type of toolbars to process in each template). The read-only is obvious what it means. An example of a read-write toolbar is the recent-product history (introduced above), i.e. the recent-product-history would update the user's product views history every time it is rendered.

What others think?

I'd rather require the developer to insert the include tag manually.

At the very least the check to determine whether to include the curriculum bar should be fast and not incur any db overhead, should check that it be mounted and not merely installed, and has be fast (that or we need to remove curriculum from the site-master/default-master and provide instructions on how to include it instead).

So, despite the objections to the principle of having ad hoc checks in the template, I won't remove it after all. (One reason why I don't mind keeping the check is that I think there will be less confusion about what Curriculum offers, and less support calls, too.)

I've hosed my own oacs development copy at the moment as I am in the process of debugging my new caching solution in curriculum::conn, so I'm holding off improving the curriculum check in site-master.tcl until I get things straight - which should be today or tomorrow.