Forum .LRN Q&A: Renaming static portlets

Posted by Janine Ohmer on
I'm not sure whether this is a bug or merely poor design, so I'm seeking opinions on what to do.

In .LRN you can edit portal templates, which means arranging the canned portlets and adding static portlets.  These templates are then used to set up the portal layout when a new user, class, etc is created.

When you go into a portal template and edit one of the static portlets, it does the following:
- update content and pretty_name in static_portal_content
- call portal::set_pretty_name, which updates the name in portal_element_map

The problem here is that every instance of this static portlet, meaning one for each user, class, etc has a row in portal_element_map, and the only one being updated is the one that's associated with the template.  So the change to the pretty name does not propogate out to all the places where the portlet is actually used.

The root of the issue is that the portals code is responsible for fetching the pretty_name, while it calls into the static-portlet code to retrieve the content.  If pretty_name were returned along with content then all would be well, but it isn't.

I think the right way to fix this would be to add a proc that would set the pretty_name for all instances of this static portlet.  However this doesn't seem to be possible;  I can't figure out a query that will give me all the elements of a particular datasource type for a specific theme.  There doesn't seem to be any mapping from elements to themes.

Suggestions?  Is this currently fixable, or does it need to wait for Don's new-new-portal rewrite?

Posted by Caroline Meeks on
As I recall static portlets has some serious design flaws.  Top of my gripes with it are not using the content repository and having a limit of 4000 characters.

If I had time I'd like to rewrite/replace static portlets with a portletized view of an "edit-this-page" like CMS that provided richtext data entry, versioning and symlinks.

Then I'd write a UI to to allow group administrators to designate specific portlets' content publically visible and serve this content on separate non-portalized pages, perhaps outside of the dotlrn heirachy on the site-map. The goal is to give each class/club thier own public (or registered users only) pages viewable by non-group members. This is an important feature missing in dotLRN.

I actually think this would be pretty easy to do with BCMS.

Simple Use Case: Allow students to browse classes without joining. If the content of the "Class Info" was public we could link that page from the "Join a Group" page and allow students to browse course before they joined.

Posted by Janine Ohmer on
The 4000 char limit is gone in 5.0;  that's one of the fixes I submitted a while back.