A portlet container needs not be tied to any particular framework, e.g. an
architecture like this can avoid any dependency of a portlet container
implementation to the framework on which a portal that uses the container
is built:
Portal | Portlet Runtime Env
+------+ +-------+ | +---------+ +-------+
|+------+ |Portlet| | |Portlet | |+-------+
+|Portal|<->|Invoker|<-|->|Container|<->+|Portlet|+
+------+| | I/F | | | | +-------+|
+------+ +-------+ | +---------+ +-------+
The portal could be based on any framework, be it Struts, Turbine, or
something else. Also, many different portals may use the same comtainer.
Typically, the portal needs to call portlets for purposes such as
dispatching events (e.g. action events or window events) to portlets so
they can react on those events and for obtaining markup from portlets. The
PortletInvoker interface to be used by portal implementations for invoking
portlets needs to have corresponding methods that are additionally taking
portlet identifiers and portlet instance identifiers as parameters that
identify the target portlets to invoke.
Best regards,
Thomas
Thomas Schaeck
Portal Architect
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
"Ignacio J. Ortega" <[EMAIL PROTECTED]> on 12/22/2001 07:05:29 PM
Please respond to "Jetspeed Developers List"
<[EMAIL PROTECTED]>
To: "'Jetspeed Developers List'" <[EMAIL PROTECTED]>
cc:
Subject: RE: New API specification
> De: David Sean Taylor [mailto:[EMAIL PROTECTED]]
> Enviado el: martes 11 de diciembre de 2001 20:45
> I would like to start a new cvs for Jetspeed-2, similar to
> how Turbine now
> has Turbine-2 and Turbine-3 repos. Jetspeed-2 would be based
> on the Portlet
> API, and a Portlet Container SPI.
+1
> From reading the postings on the emails, and from personal
> experiences,
> there is some question as to whether we should continue to
> base Jetspeed on
> the Turbine framework.
> I see some basic framework choices available at jakarta:
>
Keep in mind that we are producing right now 2 separate things, a
portlets and protlet container spec, and a implementation of that spec,
so we should try to implement it in as various frameworks as we can, i
know this is very ambitious, and I can sound as dreamer, but that's my
opinion..here we go.. ( my votes are only indicative of personal
preferences not strong opinions.. but no time to start any of them )
> * Avalon?
I do not see that, i know very little of Avalon, my only experience is
from Cocoon2 use of Avalon..
> * Cocoon-2
I do like very much that option, and leveraged so many times to started
to look at there heavily, and i'm overly fascinated by their community
Some time ago Stefano made a proposal of changing the actual
agggregation engine done as generator and make a transformer.., we can
hook there, making our psml a source of for aggregation, that ideally
that a portlet is.. i dont know if there was more than words in that
aggregation engine, but i think this a good start point..
What i think fails there is the action processing capability, i need to
study a bit how this is done in cocoon2, but i can recall it is very
poor compare to turbine.. it seems this will be much improved in Cocoon
2.1..but i dont know how this will end there :), may be they will use
scheme and thats are fat words.. :)
+1
> * Struts
I like struts and i use it in my own projects, but i fail to see
JetSpeed as Struts app, i need to restate my study of struts to see how
can we implement a portlet container there..
0
> * Turbine-2
?�?�?� a next portlet container planned in a past Framework?
-1
> * Turbine-3
Well the easy path.., i'm getting used to turbine 2, how big will be the
step from 2 to 3.., a complete api change ?
+0
> * none
We can consider to create our own framewok, but i dont like this way, i
think we are producing implementations of portlet containers not
frameworks ..
-1
> IMO, we are not leveraging jakarta-commons, and we should be.
> When looking to refactor the jetspeed architecture, we should
> have a good
> knowledge of all the apache projects and their capabilities. I will be
> spending the next few weeks doing exactly that.
Agreed
Saludos ,
Ignacio J. Ortega
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
