> De: Thomas Schaeck [mailto:[EMAIL PROTECTED]] > Enviado el: domingo 23 de diciembre de 2001 11:46
> 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: > Agreed, i was confusing the terms, talking about the mix of portlet container and portal implementation.. > > 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. > JetSpeed 2 will be a the sum of 3 things instead of 2: 1) Portlet Container and Portlet Specs.. 2) A Portlet Container Implementation, independent of any framework 3) A Portal implementation, framework dependant.. > 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 Which is your idea of the methods to transmit markup between layers? like it's now? adding SAX to the mix? > 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 > Many Thanks .. for jump in and the brief clarification.. still learning.. I need urgently to read the portlet spec present in the CVS ;) Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
