Forum OpenACS Development: New "header" class in dotlrn and site master

Collapse
1: New "header" class in dotlrn and site master
Posted by Jose Pablo Escobedo Del Cid on 05/17/06 06:21 PM

Hi all,

As I posted a few days ago, I want to remove the tabs and header stuff from the dotlrn-master when the page is being called from an frame.

I can't create my own master because I don't want my package to change the whole subsite template, and since the page is called from a frame, I can't neither just put a <master src=path> in the adp file.

I spent some time trying to find a way to do this but I couldn't find one.

The current hack that worked fine is to add a "class=header" in all the divs that I don't want to be displayed and with a javascript detect if the page is being called from inside a frame, and if it is, mark the divs as hidden (style=display:none).

The patches are here:

Can I commit this?, Is there another way to do this?

Collapse
2: Re: New "header" class in dotlrn and site master (response to 1)
Posted by Rocael Hernández Rizzardini on 07/13/06 04:58 AM
I like this, here are my comments:
I suggest an even-less invasive approach.
Now you can use the header_onload & get_extra_headers callbacks, so you can include whatever you want from wherever you want.
http://www.openacs.org/forums/message-view?message_id=461497
Also, instead of class=header, better to use the actual ids, and just play with them and javascript, here's my approach:

<script type="text/javascript">
if (top.location != location) {
var siteheader=document.getElementById?document.getElementById("site-header"):null;
siteheader.style.display='none';
var contextbar=document.getElementById?document.getElementById("context-bar"):null;
contextbar.style.display='none';
var navbarx=document.getElementById?document.getElementById("navbarx"):null;
navbarx.style.display='none';
}
</script>

Plus you avoid a loop among all the possible divs.

Collapse
3: Re: New "header" class in dotlrn and site master (response to 1)
Posted by Daniël Mantione on 07/13/06 11:06 AM
This causes trouble with progressive loading on some browsers, the headers show first, but as soon as the browser starts executing the Javascript (usually when the entire page has loaded), it disappears.
Collapse
4: Re: Re: New "header" class in dotlrn and site master (response to 3)
Posted by Rocael Hernández Rizzardini on 07/13/06 04:08 PM
yes, you're right. Any work around for this at the client side?
Collapse
5: Re: New "header" class in dotlrn and site master (response to 1)
Posted by Dave Bauer on 07/13/06 04:27 PM
You basically want to suppress the master template.

What I did for LORSM where we want to display an assessment without the site template, is to make all the pages I want to use an include, then include them in LORSM without the master tag and use them within assessment with a master tag.

I imagine there might be a way to create an include tag that somehow supresses the master tag, if the included page has one.

This would very easily solve the problem, but I couldn't figure out how to do it yet.

Collapse
6: Re: New "header" class in dotlrn and site master (response to 1)
Posted by Dave Bauer on 07/13/06 04:28 PM
I think the include without master option is so much simpler, less error prone, not dependent on javascript, and reduces the amount of unused code and data sent to the browser.
Collapse
7: Re: Re: New "header" class in dotlrn and site master (response to 6)
Posted by Rocael Hernández Rizzardini on 07/13/06 04:53 PM
We did a server side solution, which is modify the master template (ie. dotlrn-master), if you're inside lors for instance, the headers will be not shown (using cookies).
Collapse
8: Re: Re: New "header" class in dotlrn and site master (response to 6)
Posted by Jose Pablo Escobedo Del Cid on 07/13/06 05:23 PM
I think that from the 3 options mentioned so far, the one Dave proposes is the cleaner. However, is the one that takes more time to implement.

Working with javascript is our current solution, but as Daniël mentioned, sometimes it doesn't work fine on some browsers.

An finally, I prefer not to work with cookies if I can ;o)

There was another idea we *thought* some time ago, and it was to modify the master-template adding a flag to it, and somehow, if the flag was set to true, for instance, do not take the master-template from the parameter, but from another location, or simply, do not get/show the master-template at all.