Home
The Toolkit for Online Communities
17203 Community Members, 1 member online, 2217 visitors today
Log In Register
OpenACS Home : Forums : .LRN Q&A : Proposal - New Portlets package and standard (non-dotLRN dependent) package portlets move to OpenACS

Forum .LRN Q&A: Proposal - New Portlets package and standard (non-dotLRN dependent) package portlets move to OpenACS

Icon of envelope Request notifications

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?

<blockquote><i>
Is there a good technical reason for keeping portlets unbundled from their base packages?
</i></blockquote>

No, I don't think there is any reason. IIRC, that was the plan when myself and Kapil were going to work on a new portals package (Sep. 2001). Of course we didn't think in portlets terms at the time but the idea was the same.

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?

Good point ... I'm sort of leaping ahead under the assumption that we'll eventually write a portal-based admin UI, meaning we'd know the portal datamodel would be available.

Perhaps others want to comment.

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.

I am coming from a low technical perspective here.... I have little exposure to dotLRN or portlets.  So bare with me.

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?

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.

Thanks Deds.  So I guess it maybe a feature list for 4.6 or 4.7.

(this post will travel take longer to get to Deds even at eletronic form... than just tapping Deds shoulder :) )

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.

Hi Don,

Thanks very much.  Deds also showed me this feature.  I just recently got dotLRN CVS.  If I have time this weekend I will try it... maybe atleast next time my post will be more in context.  Thanks to you both.