That's a relatively simplistic answer, not really I was driving at. People are going to need to work on the portal end of things too (which I indicated by including integrators btw). The JSR 168 API is really only about the portlet itself as you pointed out, The details like layout and such are left to the portal vendor, and if you are saying you only support users using the JSR 168 API no-one will want to use your portal. For that sort of simplistic use you might as well use the container that comes with pluto to run your portlet in.
What if I need to do things at the session level, what about the security interface, isn't that user modifiable what about interportlet communication which is explicitly out of the spec? How about administrative functions, role management, etc. These are all things the user will want access to and are definately not part of the JSR 168 spec. The only value a particular portal implementation adds is in these sorts of things, not just a strict JSR 168 API. The value a portlet brings is portablility obviously, but a portal is way more than JSR 168!
Come on, I was couching my question in simplistic terms to avoid confusion and focus on details, not because I wanted a simplistic answer.
-tk
At 09:41 AM 10/24/2003 -0400, Weaver, Scott wrote:
> Is Jetspeed 2 going to address that by separating out the user api > (events/action, etc), the integrator api (security interfaces, etc) and > the > core api (all the guts you can't/shouldn't change) into separate > jars/javadocs, or will there be pages and pages of javadoc to plow through > including pipelines and valves and other non-user configurable stuff just > to get a portlet to display Hello World?
This is the whole idea behind the JSR 168 standard. To get your portlet to work, you just deploy it, that's it. You shouldn't have to know squat about how Jetspeed works internally. Your portlet should never (if it wants to stay portable) need/have to directly access any resources within the Portal.
> Is Jetspeed 2 going to address that by separating out the user api > (events/action, etc), the integrator api (security interfaces, etc) and
Jetspeed 2 uses the JSR 168 model of one action and multiple renders per request. To stay compliant we should not stray from this. The api is pretty cut and dried on this approach.
There is really no other user api apart from the portlet-api.
Regards, *================================* | Scott T Weaver | | <[EMAIL PROTECTED]> | | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | *================================*
> -----Original Message----- > From: Todd Kuebler [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 23, 2003 6:40 PM > To: Jetspeed Developers List > Subject: Jetspeed2 - User .vs. Integrator .vs. Core API/jars > > > IMHO one of the greatest barriers to entry to Jetspeed 1.x was the mixing > of the core API with the end user API. > > Is Jetspeed 2 going to address that by separating out the user api > (events/action, etc), the integrator api (security interfaces, etc) and > the > core api (all the guts you can't/shouldn't change) into separate > jars/javadocs, or will there be pages and pages of javadoc to plow through > including pipelines and valves and other non-user configurable stuff just > to get a portlet to display Hello World? > > > -tk > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
