[EMAIL PROTECTED] wrote:
> Raphael Luta wrote:
>
> > I think an application neutral Portal API is possible but
> > would certainly leave
> > a lot of responsabilities on the portlet developers,
> > especially if we aim for
> > multi-device access. More on this when I have finished my
> > Jetspeed 2 paper...
>
> Can't wait until then ;-)
>
> I would think that a device negotiation layer as you could call Cocoon would
> be extremely helpful working towards different devices - it does already
> quite a lot of things in terms of user agent detection and the like.
>
It should deal also with content-type/content-encoding. WAP phones accept WML,
but also HTML and other content types that the gateway knows how to translate.
Thus a portlet that can deliver only HTML can be left as a link in the WML page,
and the gateway will try to translate when clicked. If you look to the accept:
header that my phone produces, it has something like 20 content types, most
being translated by the WAP gateway.
>
> > The Cocoon project will mainly work on *static* content
> > aggregation so that
> > they can offer the same functionalities than Turbine layout model. A
> > Jetspeed implementation on Cocoon 2 will definitely take
> > advantage of their
> > work in static aggregation but I don't see currently a way to
> > integrate
> > in a meaningful way dynamic aggregation in a Cocoon 2 sitemap.
>
> What do you mean with dynamic aggregation? User-based? From what I
> understood of what Giacomo told me, the Action component is the way to go
> for all things dynamic in Cocoon(2).
>
I had a talk with Giacomo about the Action. He reccomended us to define a
Jetspeed Action, that would take care of disagregation of parameters,
namespacing, etc., and then call our actions for the Portlets. But wa also need
some way to manage URI namespace. A portlet should be able to use whatever
parameter names, but there should be no collision on this namespaces.
Somehow, we are managing two scarce resources:
- The page as a unique document that all portlets must share
- The URI as a unique event dispatching tool that all portlet must use
(specially webapps)
Portlets should have mechanisms to manage the document and the URIs (as if they
are unique to them), and Jetspeed should hide and manipulate the "true"
resources in a clean way.
There were some discussions about a portlet API. People expressed concerns
wether it was needed. I would say it is needed, but I would say also that it is
too early to do it.
They also say that we could do all manipulations of the HttpRequest and
HttpResponse objects, so that any servlet can act as a portlet. I would say this
is feasible, but it would be computationally not efficient if we must strip HTML
tags, negotiate content types, ...
>
> </Steven>
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
