Portals and portlets

dotLRN includes a replacement portals package that should be used to replace the current OpenACS portals package. The improvements are so obvious and significant that I won't bother listing them here.

I would like to see us remove the existing portals package entirely and to include the one written for dotLRN. I personally see no need to keep the name "new-portals" as the name, we could just call it "portals".

It looks to me as though there's still work to be done on the UI. In dotLRN portals are added to pages automatically by the applet mechanism so there's not so much need for a complete UI for portals themselves. This can be addressed later by the OpenACS crew.

So, then ... why have separate portlets packages for standard OpenACS packages?

These are simple presentation templates that could easily be segregated by name ("foo-portlet", etc) or by placement into package-key/portlets or package-key/www/portlets.

They're deeply intertwined with their base package, and changes to the base package need to be reflected in the associated portlets. Keeping portlet packages separate from base packages doubles the list of packages one has to deal with when interacting with the APM.

And I feel strongly that we want future package implementors to provide usable portlets for new packages. Describing a proper application package as being composed of datamodel, tcl library, page templates and portlets would naturally lead to people thinking of portlets as being necessary components of new packages. Splitting them into separate packages would encourage implementors to think of them as being optional or something to be left for the future.

Also, eventually I'd like to see us move to a portal-based admin UI with admin portlets provided for each package, possibly in 4.6, certainly in 4.7, with the acs-subsite package responsible for building a control panel page which includes admin portlets for packages mounted underneath it. The control panel concept first appeared in ACES, is now included in the standard ACS 3.5 release maintained by Sussedorf and Roy, and has been implemented in dotLRN as well. It's a good concept.

Why not incorporate it into OpenACS 4?

This implies that application packages would be required to include, at minimum, admin portlets, which strengthens the case for not separating portlet and base packages.

Is there a good technical reason for keeping portlets unbundled from their base packages?

I support putting all of these packages in OpenACS 4.

I wonder if there is still a reason to keep the portlet packages independent,
though (although still part of OpenACS 4, obviously). If people want forums
without the portal interface, they should be able to do so. But if they then
install portals, they should also be able to install forums-portlet. Seems like
separate packages can still help here for maximal flexibility?

Don,

You might want to point to this from the General forum.

I think a portal based admin would be very powerful. Roberto and I were discussing making the My Workspace page easier to add items to. With a portals based system, is it already done.

If portals is part of the core, i see no reason to keep the portlets as seperate packages.

Will the new portals / portlet address this issue. For example on my site which has 2 portal page. Both page has a portlet to bboard. One portal page has many contents and the bboard portlet only shows the title of the post. The other is less content so the bboard portlet shows the title, date and author. Can this be done with the new portlets/portals? That is much out of the box/code?

Not supported out of the box. Two options to choose from, either create two portlets, or one portlet with a passed-in parameter to determine if contents will be displayed.

All packages can have any number of portlets, they're just templates.  The calendar package is an example of a package that offers more than one (actually many offer admin and mere mortal portlets, too).

And adding your own custom portlet is easy.