Home
The Toolkit for Online Communities
17607 Community Members, 0 members online, 2645 visitors today
Log In Register
OpenACS Home : Forums : .LRN Q&A : navigation changes in dotLRN: RFC : One Message

Forum .LRN Q&A: Re: navigation changes in dotLRN: RFC

Collapse
Posted by Andrew Grumet on
I've looked this over a bit more.

Regarding the big issues, yes I agree the tabs probably shouldn't be their own portal, if the aim of the navigation is that they should be pretty consistent no matter where the user is.

* My Workspace
* Courses
* Preferences
* Control Panel

Except for Courses, these are all standard OpenACS pages, which makes me think we should create similar page for Courses that either invokes or copies or shares the code that powers the Groups portlet (dotlrn-main-portlet.*).

To highlight the tabs, if we agree that the tabs should be at fixed URLs (not inside portals), then we should be able to compare the current URL against a the URL for each tab and highlight accordingly. Theses comparisons could be made cleanly, I'm pretty sure, e.g. relative the dotlrn instance URL for the Courses and Control Panel URLs, or by querying for the HomeURL kernel parameter for Preferences.

Another way is for the special pages to send the information back to the master template, either through attributes to the <master> tag or via globals. This would require changing at least one core page (/pvt/home). Might not be ideal.

Smaller stuff:

There's an install script for Oracle now.

Malte, I've committed over a few files based on what was in Jeremy's last tarball. These were notably different from CVS, even taking the navbar_list code into account, and looked better. The commits preserved the navbar_list code chunk in selva-master.tcl.

The tabs don't render well in IE.

The tabs don't resize well in Firefox/Windows.

The portlet headings (Groups, Forums, FAQs, etc) render inside the portlets, not outside, as they do on the sample page.

Collapse
Posted by Jeremy Monnet on
Thanks for all this Andrew.

I am sorry for answering late, last week was a conference week in Sydney, so I didn't work for this ...

I think you're right, and the only way to have these static tabs is to have a static page behind (I mean as you wrote "standard OpenACS pages") so I'm going to look in this way.

As their link will be static (e.g. "/pvt/home") we can compare directly with "ad_conn url" I think ?

I would not like to send info back to master template. As you said it would mean modify some core pages, and I don't want to break everything ;-)

For IE/Firefox/windows : I am sorry, I haven't tried this yet with windows (although I must say I was expecting trouble with this ...)

The protlet headings are inside because we must change the sloan-theme.adp file (new_portal/www/themes) for separate title and content, and use our tags by the way.

So I have two questions now :
-> I've seen that some files are available directly (/www and /packages/acs-subsite/www for example). Where part of the documentation decribes what pages are or aren't accessible ? Is it part of the request pre-processor, or something else ?
-> Is it possible to use a portlet in a "standard OpenACS pages" ?

Jeremy

Collapse
Posted by Jeremy Monnet on
Ok I found the answers to my questions :

-> Yes, I can call a portlet directly
-> I have to mount the application package.

So I'll probably mount the application under /theme (Not used at the moment I think ?) and the courses tab (and more tabs maybe later) will still be in the theme package. So the system can work with our new tabs system, or when uninstalling with the current "tab-only" system ...

Jeremy