I have taken a look at JetSpeed and was very impressed except for the fact that it must run on to of turbine.... which I don't like. So ya, I would be interested in seeing this take place and would be willing to lend a hand.
Kris Sandra Cann wrote: >I was getting caught up on the Jetspeed list and just read the thread >discussing integrating different frameworks including Struts with Jetspeed. >I would be interested in hearing from people interested in using Jetspeed >with Struts and perhaps doing some collaboration on this effort. > >Sandra Cann >[EMAIL PROTECTED] > >>-----Original Message----- >>From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] >>Sent: Sunday, December 23, 2001 4:00 PM >>To: 'Jetspeed Developers List' >>Subject: RE: New API specification >> >> >>>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]> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >
