Stefan,
I apologize it took so long to answer. . .I've been out of pocket over
the holidays.
see below. . .
Stefan Armbruster wrote:
Hi,
some questions regarding architectural aspects of Pluto 1.1:
1) What's the purpose of PortalCallbackService?
The purpose is to provide a mechanism for the container to "call back"
to the portal to retrieve additional information or services it needs to
process a request. Examples are, setting a title, creating a url, etc .
. . (and other portal dependent concepts).
2) The portal pages contain various portlets. Currently this seems not be user
dependent. Assume the portal providing portlets p1, p2 and p3. User A wants
to have p1 and p2 on his page, whereas user B wants p2 and p3 on his portal
page. In order to do so, the methods in RenderConfigService need to know
about the current user. This could be easily achived by adding
HttpServletRequest to the list of arguments of getPage(String), getPages()
and getDefaultPage().
You're right, it could. We are trying to keeps pluto to be simple - to
provide a usable wrapper around the container that makes testing and
developing portlets simple but without all of the fluff of an enterprise
portal. That's why this type of portal customization doesn't exist. I
would strongly recomend that if you need this type of functionality that
you first work with the jetspeed team. They (we) are currently going
through the process of creating a lightweight version of jetspeed that
meets these types of requirements but might not be as
complex/heavyweight as the full jetspeed enterprise portal. Your
thoughts on that would be greatly appreciated.
If you find that jetspeed doesn't meet your requirements, I would
recommend that we have a discussion as to why and figure out if the best
thing would be to expand pluto or to modify jetspeed.
David
Any ideas on that?
Regards,
Stefan
