portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikki Jukka <Jukka.Ni...@novogroup.com>
Subject RE: New API specification
Date Thu, 10 Jan 2002 10:40:14 GMT
When there's proposals about using frameworks with new APIs I'd like to
understand where and how these frameworks would be used. While browsing
throught 1st draft of new API and WPS documents about IBMs current
implementation possibilities
(http://www-3.ibm.com/software/webservers/portal/library/InfoCenter/) I
found two places

1. Portal server default implementation i.e. jetspeed ui
2. Portal applications views i.e. business logic

Basic operations might look like this, separating portal server from
portlets living inside container

            -----------------      --------------------
--------------------------------
   User --> | Portal server | ---> | Portal Container | ---> | Portlet, part
of portlet app |
            -----------------      --------------------
--------------------------------

It seems clear that most (all?) templating engines can be used to build view
of portlet, but whether portal server should be built using portals or is it
built using some other technique is a question and if it's built using
portlets what kind of view building solution it uses then.

If portal server is implemented using portlets it might look like this

            -----------------      --------------------
--------------------------------
   User --> | Portal server | ---> | Portal Container | ---> | Portal
navigation panels, etc|
            | flow control  |      |                  |      | default
implementation       | 
            -----------------      --------------------
--------------------------------
                     |             --------------------
--------------------------------
                     ------------> | Portal container | ---> | Portlet, part
of portlet app |
                                   |                  |      | My favourite
technics        |
                                   --------------------
--------------------------------

There could be possibility to customize your own portal instance with any
kind of templating system by writing your own implementation of portal
navigation panels, etc. if needed.

Is this correctly understood? It will be long way before new RI of portlet
server and container will be ready and there might be debate about what
frameworks it will use, but it seems possible to pass this question to
developers itself if usage of framework is pluggable and default
implementation can be substituted with new one easily .. In fact then there
would be some kind of 'skins' for portal servers that could be packaged and
could be developed with various techniques..

To summarize: If portlets are used to create portal server views it creates
architecture that allows developers to use multiple frameworks to produce
packages that contain portal skins and applications. This way enthusiasts
could use things they love while corporate developers could follow standars
created by industry.

- Jukkis

----- Original Message -----
From: "Sandra Cann" <flying_cloud@prodigy.net>
To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Sent: Wednesday, January 09, 2002 4:00 PM
Subject: RE: New API specification


> Snip
> > 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..
>
> I have a particular interest in seeing Jetspeed Portlet API and
Struts/Tiles
> integration. I am delighted to see the direction of considering other 
> frameworks to integrate with and particularly that of Struts. Using
relative
> community sizes as a gauge of market size, the Struts community is 
> more
than
> twice the size of the Turbine list so by offering the choice of 
> framework you can surely strengthen the acceptance of the Jetspeed 
> project further.
>
> By integrating with Struts this will also make Jetspeed available for 
> integration with the Expresso Framework and Jcorporate's collaborative 
> applications - since as of version 4.0 Expresso is based on Struts. In
your
> list of frameworks Expresso (www.jcorporate.com) was not mentioned and 
> perhaps should be since it is has the largest framework community with
more
> than 4300 developers on its listserv. By estimates the combined 
> Expresso/Struts communities accounts for ~85% of OSS Java framework
market.
>
> snip
> > > * 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..
>
> Has there been any progress here?
>
> snip
> >>  As to the framework choices, I do not know enough to form an 
> >> opinion.
> >>
> > Same here ;-)
>
> By keeping the Struts list appraised there may be people from that 
> list willing to help - creating a knowledge transfer.
>
> I know there are many people in our community interested in Jetspeed 
> too
and
> there would be community interest in collaborating with the Jetspeed 
> list
on
> the Struts (and Expresso) integration. Please consider the opensource 
> listserv (opensource@javacorporate.com) as a resource available to 
> this
list
> :).
>
> I will also create a forum on the jcorporate site for our community
members
> to discuss this. If anyone here wants to join this group let me know 
> offlist.
>
> Sandra Cann
> scann@jcorporate.com
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:jetspeed-dev-help@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:
<mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:jetspeed-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message