portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ming Fai" <ming...@hongkong.com>
Subject RE: odd questions about jetspeed (from jetspeed-user thread)
Date Wed, 16 Jan 2002 05:08:58 GMT
thanks for all of your response. it seems my follow up question should go to
the dev mail list.

I hope I had not use the generic terms like 'portlet api' and 'Jetspeed
library' that may create additional meaning. Let's take it to the coding
level.

just assume I write a java bean, I do the following to render a *single*
html page:
1. import all classes below org.apache.jetspeed.*
2. write a psml
3. take all necessary .xreg and .properties files from the /conf directory
4. In the bean
	a. declare and initial some PortletFactory(?), Portlets, Controller
objects, (etc) and
	b. call the corresponding methods to load the psml, (as well as to load the
.xreg)
	c. call the coressponding methods to rend the psml to html stream/string
5. Pass the output stream/string to jsp/servlet to display

Is it theoritically possible? (and assume i just take the classes but not
modify the source)

It's just a hypothetical question. And it may take a sigificant time without
much obvious benefit. In such scenario, I use jetspeed/portlets without
using turbine. And it shows the 'portlet api' is independent of any
framework. (interoperability?!)  I am not focus on portability at this time
as the spec is not finalized.

> For what you are looking currently, a publishing framework like Cocoon
> can help you (again, no library). But still you will miss some features
> thar are present in Jetspeed and Turbine.

Yup. I see there are a few benefit for using portlet in compare to other
publishing frameworks,

1. high managability
	- manage layout in the xml/psml file
	- can use customizer to manage the layout
2. Layout Customization
	- customize the layout *by the user*
3. Dynamic content
	- if the content source of a single portlet is dead, the page still can be
rendered
4. Easier Personalization and security (just read the new discussion!)
	- at portlet level

I pick Jetspeed! :)

regards,
mingfai


> -----Original Message-----
> From: Santiago Gala [mailto:sgala@hisitech.com]
> Sent: Wednesday, January 16, 2002 7:30 AM
> To: Jetspeed Users List
> Subject: Re: odd questions about jetspeed
>
>
> Ming Fai wrote:
>
> >i've two odd questions,
> >
> >1. can I use Jetspeed without Turbine?
> >2. can I just use Portlet API of Jetspeed? (hopefully, the future JCP
> >Portlet API standard)
> >
> >basically, two questions are the same.
> >
> >what i mean is not leaving the Turbine features there without
> touching them.
> >But to take out the Jetspeed library and use it elsewhere. Take the
> >simpliest case, I want to make a simple site in sgml, and I use jsp to
> >render the sgml to html by the jetspeed library. Is it possible?
> >
> Jetspeed depends a lot on turbine:
>
> - The turbine layout mechanism (layout, navigations, screen, actions,
> rundata) is used.
> - Quite a few services (userManagement, rundata, object pools, ...)
> - The current portlet api is dependent on turbine (this should change
> when we go portletAPI)
>
> There is no such thing as a Jetspeed library. You can have an idea with
> the Servlet API. What you would call Servlet library is a Servlet
> Container (like Tomcat, Resin, Caucho, JRun).
>
> Currently there is no standard so that you can exchange portlets between
> different servers (like in the Servlet API). This is what the jsr-162
> and jsr-167 are about.
>
> For what you are looking currently, a publishing framework like Cocoon
> can help you (again, no library). But still you will miss some features
> thar are present in Jetspeed and Turbine.
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:jetspeed-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:jetspeed-user-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