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

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.