Forum .LRN Q&A: Linking to arbitraty URLs from community navigation

We'd like to add a link to content external to the community to the community navigation bar.

I this case a community will have a wiki page in a sitewide wiki and we want to link to it from the community navigation bar.

This should be possible be adding a portal page, and adding a new paramter to the portal page of a URL to link the page to.

A more complex solution woul dbe to add a "redirect-portlet" and have the portlet paramter add a page with a link. We'd need to be able to add one or more links so the portlet would need to support having items on more than one page. (Xowiki portlet already does this for internal wiki pages).

I am looking for advice in designing this feature.

I know Don has done the most with the portal package and his feedback on how to implement this cleanly would be appreciated.

Collapse
Posted by Dave Bauer on
Interesting.

Right now page rendering of portal pages is tied to dotlrn, the code that actually renders the page is in the dotlrn package.

Here is the simple solution we did for one client.

1)Add url column to portal_pages table. (new-portal package)
2) Add a place to set the redirect url on the portal layout page (dotlrn package)
3) Add code to redirect if url is set in the one-community page (dotlrn package)

The point is to add items to the class navbar. Another simple option is to add a parameter to the dotlrn package instance to set the navbar like we do for the dotlrn-wide navigation tabs.

Something like: [list $page_num $url] where any page number that needs to be redirected will have a url associated with the page number. Page numbers appear in order in the navbar. You could add a blank page, and name it the name you want for the link. There isn't any user interface for the parameter though. Of course this only really affects .LRN.

Don, how does this fit into the rewrite of portals you did?

Collapse
Posted by Don Baccus on
new-portal is hopelessly tied to dotlrn, so don't worry about making it worse. It's a dead-end outside the dotlrn environment.

As far as my rewrite of portal goes, it works fine as a standalone package and has master templates that work with acs-subsite. It knows nothing about .LRN. I gave up the notion of re-integrating it with .LRN primarily due to upgrade problems and due to my general disgust with .LRN internals. I did, at one point, have it working with .LRN but doing so required keeping some of that tight .LRN/portal integration around (ignored from outside the .LRN environment).

So come up with the cleanest solution you can think of regarding the .LRN environment ...

Rewriting .LRN's the preferred solution to pretty much everything but that's a pie-in-the-sky dream at the moment, I'm afraid.