Forum OpenACS Q&A: .LRN Portal Framework in OACS?

Collapse
Posted by Randy O'Meara on
I remember some time back that someone (maybe Don) was merging, or going to merge, the .LRN portal framework into OACS. Is this project started, completed, abandoned?
Collapse
Posted by bob phillips on
Look for "portlets" in search box. this looks like what you
remembered.

Don's original post:
https://openacs.org/forums/message-view?message_id=45467

Collapse
Posted by Randy O'Meara on
Thank you, Bob.

Openacs CVS contains a weblogger-portlet package.
The weblogger-portlet package requires the new-portal package. The new-portal package is in dotlrn CVS.

Can the dotlrn new-portal package be installed and run under openacs 5.0 without installing dotlrn?

If it's not possible to use just the new-portal package from dotlrn, must the entire dotlrn system be installed and initialized in order to use new-portal?

Collapse
Posted by Jeff Davis on
There was one dependency between dotlrn and new-portals (see bug 1181). I just moved the files from dotlrn/tcl to new-portal/tcl so that should no longer be an issue. I know Lee Denison is using it that way now (which is why he spotted that bug) so I don't think there are any other roadblocks.
Collapse
Posted by Randy O'Meara on
Thank you, Jeff. I'll give it a try.
Collapse
Posted by Randy O'Meara on
Yes, new-portal does install under oacs 5.0.

Is there some body of information that describes how to use the portal system? I have also installed weblogger-portlet and news-aggregator-portlet.

Thanks,

Randy

Collapse
Posted by bob phillips on
A good question about documentation. Part of the problem
seems like an case of multiple names for the same function. portlets seems like an instance of templates???

---------

quoting baccus:

"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."

----------------
Ben Adida wrote:

http://dotlrn.collaboraid.net/dotlrn/doc/writing-a-dotlrn-package

an overview.

It references a page called "new portals architecture" which
has disappeared.  !!!

------------

https://openacs.org/projects/dotlrn/roadmap

mentions portlets and documentation, but no references.
send money. !?

------------
https://openacs.org/doc/openacs-HEAD/apm-design.html

is current (pre-release) document for package management

-------------

and finally
https://openacs.org/doc/acs-templating/
the root for templating

Collapse
Posted by bob phillips on
randy, did you have a new portlet idea in mind?
Collapse
Posted by Don Baccus on
Well, not only can one package offer multiple portlets, but any package can offer a portlet to render the contents of another package (like forums) that offers a comprehensive datamodel.

See the recent thread in the OpenACS development forum.

As far as integrating portals into OpenACS proper ... originally Open Force started a rewrite/improvement before they dropped out of the community over our power struggle/war and later Ben dissolved the company, before the rewrite was finished.

I looked last summer into completing it and got it nearly to the point where page rendering worked then got distracted with other (paying) work.

At this point, in our OCT meeting this morning (total coincidence) I suggested we just improve the .LRN new-portal package and abandon the rewrite.  The existing code, though not beautiful, appears to work well and scale reasonably, and with so much existing code depending on it, switching to the rewritten version would require complex and maybe dicey upgrade scripts.

So we're going to live with the first cut .LRN portal package.

Perhaps a good argument for good design and implementation the first time?  The "plan to throw the first one away" argument is a good one but only for those who don't actually have users or customers using the first cut code.  A lesson, perhaps, that if you don't want to be stuck with your prototype forever, don't release it but do your improved version and release that.

Whatever ... the existing new-portal package is very functional and though not beautiful we can deal with that.  Including incremental improvements over time that don't flat-out break code that relies on it.

So. Bob, is it true you're going to buy me an EOS 1DS for xmas?  No?  Damn!

Collapse
Posted by bob phillips on
I must have missed the thread in dev... which name?

------------
as for cameras...

ahhh an OT to savour!

don: how many megapixels will satisfy?
rumours of 9 for prosumer next summer. probably implies
a bump for the pro cameras?

Collapse
Posted by Talli Somekh on
whoa.... Bob is Santa Claus? NOW it all makes sense.

Too bad I'm too Jewish. I'm not allowed to believe in Bob.

I'm also too old to believe in such things. Although that didn't stop Vinod from asking the Tooth Fairy to marry him...

talli

Collapse
Posted by Dirk Gomez on
Also read the Mythical Man Month - recently reissued me thinks. It has a good chapter on what happens if you throw away the first design because it was too crappy. It is chapter 5 - The second system effect (to which I and others had refered to a couple of times)

The .LRN portal framework code is awful and contracted, but it cuts it for the user. We should stick to it for the time being until someone has a compelling replacement.

As it is very unlikely that someone will have a compelling replacement we should continue to work on the current code :)

Collapse
Posted by bob phillips on
regarding the choices between continuing current code or
redesign, I'll have to defer to those with better knowledge of
the code.

The only thing that strikes me is the absence of a work estimate for the proposed change. Until I know the scope of the work and see the particular items on the list, it's hard
to know about the cost.

It might be less than that spiffy camera?!

Collapse
Posted by Don Baccus on
The cost of finishing the rewrite isn't that much (and, Dirk, it's really a cleaning up, not a total reimplementation, organizing pieces into logical namespaces, simplifying the datamodel slightly, etc).

The cost lies in munging all the client code to make use of the new version, and that would include third-party code not controlled by us, i.e. anyone who's customized a .LRN portlet or (as we're now seeing) uses the portal package outside .LRN.

And (much worse) the writing of upgrade scripts for current .LRN users.

As usual it's the support tail, not the development per se, that's the nasty bit and I just don't think it's worth it ...

Collapse
Posted by Randy O'Meara on
Thank you for the links, Bob. I don't have a new portal idea. I would like to know what is offered by portals, how to create a portal page, how to add elements (portlet or applet?) to a portal page, and how to aggregate content on a portal page/element.

The documentation that does exist doesn't provide adequate information to satisfy these needs.

Randy