Hi,
I posted the log of the PortletAPI chat some days ago. As there where no
responses, I assume that nothing is left to discuss with regard to the
issues we talked about in this chat. As we (at IBM) a very keen to start
implementing the new API, I'd like to vote about the point that we seem
Hi,
enclosed is a log of the portlet API chat on Wednesday evening. Raphael
wanted to post it, however I haven't seen any message from him since - he's
probably very busy.
I think the most imporant part is at the bottom:
raphael OK. So what we have said tonight is :
raphael - portlets should
Santiago Gala wrote:
ingo schuster wrote:
At 20:04 02/16/01, Raphal Luta wrote:
What would be the ideal time for an IRC chat ?
Personnally I'd prefer either between 12:00 and 130:00 GMT (but I
guess it's
a bit early for the PST people out there) or near 19:00 - 20:00 GMT.
Steve,
Suggestion: Add a configuration tag to the portlet definition
which specifies whether or not the portlet will produce partial
or full content.
You probably mean the deployment descriptor, not the portlet definition...
Suggestion: Create portlet wrappers for full content stripping
: Re: [vote] Portlet API - Summary and IBM Position (long)
At 07:36 PM 2/18/2001 +0100, you wrote:
1.Primary output mode
(This affects the programmatic Portlet API)
Alternatives:
a) output stream as base mode in portlet package
sax as special mode in portlet.sax package
At 20:04 02/16/01, Raphal Luta wrote:
What would be the ideal time for an IRC chat ?
Personnally I'd prefer either between 12:00 and 130:00 GMT (but I guess it's
a bit early for the PST people out there) or near 19:00 - 20:00 GMT.
Both times are ok with me. Did we already fix the day (Mo or
ingo schuster wrote:
At 20:04 02/16/01, Raphal Luta wrote:
What would be the ideal time for an IRC chat ?
Personnally I'd prefer either between 12:00 and 130:00 GMT (but I
guess it's
a bit early for the PST people out there) or near 19:00 - 20:00 GMT.
Both times are ok with me.
Thomas,
Excuse me for not being fully up to snuff...
At 10:25 AM 2/19/2001 +0100, you wrote:
Steve,
Suggestion: Add a configuration tag to the portlet definition
which specifies whether or not the portlet will produce partial
or full content.
You probably mean the deployment
,
Can you give an example of how such a stub should look like? You may indeed
have good ideas here...
Cheers,
Thomas B.
- Original Message -
From: "Steve Freeman" [EMAIL PROTECTED]
To: "JetSpeed" [EMAIL PROTECTED]
Sent: Sunday, February 18, 2001 21:32
Subject: Re: [vote] P
iMode and
WAP, maybe a digitized sound for VoiceXML. I don't believe the
container can handle these things in a generic portlet-independent way.
My concerns is that the portlet API should have a way to allow for
aggregation of content before styling as I feel it will be the way
to go in a short a
:) - Raphael
has provided an excellent description of this goal:
"The Jetspeed community has decided to start specifying a
Portlet API that could be proposed as a standard for all
portal implementations.
Offering a standard API between portals only makes sense
if the portals implementing the AP
Thomas Schaeck wrote:
Unlike the Servlet API, the Portlet API would additionaly
provide explicit SAX support in the sax package and introduce a
dependency on org.xml.sax, i.e. a separate package. Such a
dependency of an API package to another API package that is not
part of the core Java
At 20:04 02/16/01, Raphal Luta wrote:
I updated the java docs in the proposals directory so that everybody can
have a look at them. They are more detailed, but I hope that this mail
did also make the idea clear.
I still owe you a proposal that defines which rules document fragments
will have
Sam Ruby wrote:
Thomas Schaeck wrote:
Unlike the Servlet API, the Portlet API would additionaly
provide explicit SAX support in the sax package and introduce a
dependency on org.xml.sax, i.e. a separate package. Such a
dependency of an API package to another API package
At 07:36 PM 2/18/2001 +0100, you wrote:
2.Fragments and/or Full Documents
(This affects portlet container performance and ease of
implementation - and thus development costs)
Alternatives:
a) only document fragments concatenatable without post-processing
- high-performance
| C | | C |
'---'| |'---' '---' '---'
|_| aSaxPortlet aStreamPortlet aXYPortlet
I checked the boxes:
(A) provided by the Portlet API
(C) provided by the Portlet Container
(AC) provided by the API but can be replaced by the container
(U)
uot;default way" that the portlet API gurantees to work always and in every
container.
* There can be portlet containers that support only some portlet types.
Portlets do not necessarily run on _every_ portlet container, but only on
those that support their type. (This is compareable to the beg
such as "getContentHandler()" and the
specific implementation of SaxPortlet can savely cast the
PortletResponse
to ResponseImpl and make use of these additional methods
(""). We
consider this a safe break of the Portlet API contract.
Am I right to say that the PortletResponse
a very good summary of the issues.
Wer're not discussing (yet) the Jetspeed implementation, which may
support both full documents and document fragments through
configuration elements external to the proposed standard Portlet
API (for example the portlet deployment descriptors
c. Also, there is different
people doing content production and styling. We should separate the
content and style processes as much as possible.
My concerns is that the portlet API should have a way to allow for
aggregation of content before styling as I feel it will be the way
to go in a short amou
can provide additional methods such as "getContentHandler()" and the
specific implementation of SaxPortlet can savely cast the
PortletResponse
to ResponseImpl and make use of these additional methods
(""). We
consider this a safe break of the Portlet API con
and auxiliary cards. Else, the container has to limit
portlets a lot.
I think WML event/action model is much more abstract than HTML, and thus a good
starting point for
specifying how the portlet API will deal with action/event specification.
BTW, I can commit this if you want. Goes into taki
Not really. If you want to process sax events in the portal
engine, then it
doesn't make sense to convert it into a stream in the SaxPortlet and
reparse it on the other side of the portlet in order to convert it back
into sax events.
I wasn't suggesting that!
Guess I misunderstood the
ck
channel).
To me, the requirement of outputting documents looks too strong, and short term
sighted.
There is ongoing effort to specify how to describe valid XML fragments, and the trend
is
to have markup languages that follow a schema/DTD (XML).
Point 2: Should the Portlet API provide dedicated me
to this.
- Point 1 should be titled:
"Should the Portlet API require portlets to produce full documents ?"
Wer're not discussing (yet) the Jetspeed implementation, which may
support both full documents and document fragments through
configuration elements external to the propose
When we are talking about a general-purpose portlet-api, did you already
look into Oracle 9iAS Portal?
http://www.oracle.com/portals/index.html?intro.html
or
http://portalstudio.oracle.com/
They just do "recommendations" as in the current jetspeed implementation:
* Use sta
le for all of us. :-)
The basic idea is that the Portlet API defines the interfaces and default
implementations of abstract portlet classes (that are subclassed by the
actual portlets). A certain portlet container implementation could replace
these default implementations and make use of
:45 AM
Please respond to "JetSpeed" [EMAIL PROTECTED]
To: JetSpeed [EMAIL PROTECTED]
cc:
Subject: Re: [vote] Portlet API
[EMAIL PROTECTED] wrote:
I think it is useful to provide a little summary of the current state of
the discussion.
I tried to give a neutral summary on
just 2 things to add/modify to this.
- Point 1 should be titled:
"Should the Portlet API require portlets to produce full documents ?"
Yes, that's a better title, we are actually talking about the Portlet API
here.
Wer're not discussing (yet) the Jetspeed implementation,
At 22:24 12/02/2001 +0100, you wrote:
Raphal Luta wrote:
snip templating system description
Point 1:
Should the Portlet API mandate that portlet only output full documents rather
than document fragments ?
You mean here "proper" markup? This is more radical thant point 2. And
At 22:35 12/02/2001 -0800, you wrote:
Ive been reading this thread with interest. I have some comments, questions
and suggestions:
Point #1 - Portlet API mandate that portlets only output full documents
rather than document fragments:
- There is some confusion WRT portlets producing document
don't implement, I am not going to run". Portlet portability adios!
Cheers,
Thomas
- Original Message -
From: "David Sean Taylor" [EMAIL PROTECTED]
To: "JetSpeed" [EMAIL PROTECTED]
Sent: Tuesday, February 13, 2001 7:35
Subject: RE: [vote] Portlet API
Ive been readin
At 18:44 12/02/2001 +0100, you wrote:
At 14:12 02/12/01, Raphal Luta wrote:
Following the discussions on the Portlet API, there's no strong consensus
on the following points of the Portlet API and so they should be voted upon.
For those who did not follow the arguments, pleae read the "S
we diverge: the issue at hand is whether we try to create
a generic Portlet API which may fit very different model or whether we do an
optimized version of the portlet API for our planned 1.3 implementation.
You'd like to limit the API to only methods that would be useful for our
implementation
may be the odd
content that *is* a full page (eg. coming from a legacy app) but that can be
dealt with an HTML/WML/etc portlet of which a number have been reported on
lately. But the general portlet should return a fragment. And yes, ugly as
it may be, that requires the Portlet API to specify what and
Following the discussions on the Portlet API, there's no strong consensus
on the following points of the Portlet API and so they should be voted upon.
For those who did not follow the arguments, pleae read the "Secure Portlets"
thread in the mail archive before voting.
Point
Raphal Luta wrote:
Following the discussions on the Portlet API, there's no strong consensus
on the following points of the Portlet API and so they should be voted
upon.
For those who did not follow the arguments, pleae read the "Secure
Portlets"
thread in the mail arch
Raphael,
Please let us clearify your questions a bit more (see my comments below).
At 14:12 02/12/01, Raphal Luta wrote:
Following the discussions on the Portlet API, there's no strong consensus
on the following points of the Portlet API and so they should be voted upon.
For those who did
postprocessing.
If the vote on point 1 would be yes, this would result in severe
performance problems: If the portlet API mandates full documents, this
would require costly post-processing to strip off parts during content
aggregation. It is much more efficient to have each portlet write a
document
Ive been reading this thread with interest. I have some comments, questions
and suggestions:
Point #1 - Portlet API mandate that portlets only output full documents
rather than document fragments:
- There is some confusion WRT portlets producing document fragments vs full
documents.
AFAIK
Ingo Rammer wrote:
If you need some help implementing/documenting this I'd really like to get
my hands dirty. I'm somewhat used to writing
framework-documentation/how-tos/implementation guidelines as well
... so ...
just call. [hey .. my java skills are next-to-nothing compared to my
SIGN HIM UP! :)
+1024! :)
Seems that i just made some big and long-lasting mistake. ;)
Ingo
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search:
Folks,
a few minutes ago we (ie. Ingo) posted the javadocs for Portlet API 2. It is
in /proposals department in CVS. All those interested in a common standard
for portlets (hopefully even beyond Jetspeed implementations) are invited to
comment on the API.
I suggest that in about two weeks time
on 2/2/01 4:50 AM, "Thomas F. Boehme" [EMAIL PROTECTED] wrote:
Folks,
a few minutes ago we (ie. Ingo) posted the javadocs for Portlet API 2. It is
in /proposals department in CVS. All those interested in a common standard
for portlets (hopefully even beyond Jetspeed imple
on 2/2/01 1:16 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote:
the intent of this Portlet API is not only to be used in JetSpeed, we
envision this API to evolve into a standard.
+1
I'm an idiot.
-jon
--
--
To
I've made available a document summarizing the current list of requirements
for the Portlet API at
http://sda1.lotus.com/jetspeed/PortletAPI/PortletAPIRequirements.htm
User id: area51
Password: dilbert
If you want to add requirements to the list, please post a brief
description
Raphael Luta wrote:
[EMAIL PROTECTED] wrote:
I volunteer to put together a Portlet API Requirements
List that we can put on the web site. Please post your
requirements to the JetSpeed list with the topic
"Portlet API Requirements", and I'll include them in the
documen
We had very good discussions about the Portlet API for
future versions of JetSpeed. I think that we should start
to compose a requirements list to gather the requirements
for the API, listing a description and rationale for each
requirement.
I volunteer to put together a Portlet API
: 56.2.2040865
-Mensaje original-
De: Lerenc, Vedran [SMTP:[EMAIL PROTECTED]]
Enviado el: martes 7 de noviembre de 2000 7:41
Para: 'JetSpeed'
Asunto: RE: Portlet API
Hi,
I want to add some more words to the topic of incorporating documents from
the web into the portal. I am working
8, 2000 01:19
Subject: Portlet API - Regarding Different Porlet Types
Hello All!
This is a more philisophical thought train on the overall design of the
Portlet API:
I think that one of the weaknesses of the Jetspeed implementation is that
you have all these different portlet types de
that occur in these scenarios.
I think we need to differentiate between two different scenarios:
- Implementation of portlets exploiting the portal's Portlet API and
Framework, adhering to applicable design guidelines.
- Implementation of portlets that encapsulate legacy web
in a Database
| |
+-+ +-+
| Portlet | or| Portlet |
+---+-+-+-+-+
|
documents.
I've alreay notified the prowler list that they are most welcome to
participate in the Portlet API discussion so that we can be sure
to integrate with their content management system.
--
Raphaël Luta - [EMAIL PROTECTED
-Original Message-
From: Raphael Luta [mailto:[EMAIL PROTECTED]]
Sent: Dienstag, 7. November 2000 06:20
To: JetSpeed
Subject: Re: Portlet API
[EMAIL PROTECTED] wrote:
.
For handling the second scenario, complicated mechanisms
for rewriting,
handling of cookies
and Vedran Lerenc
give a good
impression of the problems that occur in these scenarios.
I think we need to differentiate between two different scenarios:
- Implementation of portlets exploiting the portal's Portlet API and
Framework, adhering to applicable design
}
and you can use hello.append('alert(6)') which looks nicer. make sure hello exists...
/m
"Schwarz, Marcus" wrote:
-Original Message-
From: Raphael Luta [mailto:[EMAIL PROTECTED]]
Sent: Samstag, 4. November 2000 13:15
To: JetSpeed
Subj
Hello All!
This is a more philisophical thought train on the overall design of the
Portlet API:
I think that one of the weaknesses of the Jetspeed implementation is that
you have all these different portlet types depending on the type of content
that the portlet is actually dealing
s from
pre-existing sources, and I always need to edit it, rewrite urls etc, before
incorporating it in the portal.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Schwarz, Marcus
Sent: Sunday, November 05, 2000 12:21 PM
To: 'JetSpeed'
Subject: RE: P
I am new to the portlet API discussion, but thought that incorporating
arbitrary documents from the web into the portal should somehow be taken
into consideration when thinking about something like a portlet API. In any
case this topic should be adressed by the community to avoid so many peo
ran Lerenc give a good
impression of the problems that occur in these scenarios.
I think we need to differentiate between two different scenarios:
- Implementation of portlets exploiting the portal's Portlet API and
Framework, adhering to applicable design guidelines.
- Implementation o
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
Sent: Monday, November 06, 2000 1:48 PM
To: JetSpeed
Subject: Re: Portlet API
Note: The most interesting part of this mail is at the end.
Micheal Rimov wrote:
snip snip
public void service( PortletRequest
leads me to think that amazon is running in full-screen
application mode.
I totally agree with you:
I am new to the portlet API discussion, but thought that incorporating
arbitrary documents from the web into the portal should somehow be taken
into consideration when thinking about something like
impression of the problems that occur in these scenarios.
I think we need to differentiate between two different scenarios:
- Implementation of portlets exploiting the portal's Portlet API and
Framework, adhering to applicable design guidelines.
- Implementation of portlets that encapsulate
for the porlet API: User/Portlet
specific consciousness per session.
Do you have any rough ideas of how the AdvancedFileServer
would work in the
future portlet api?
I just joined your discussion and need some time to catch up with you guys
on the portlet API (what you have talked about/settled
parameters would get posted ?
I'm not sure it's actually possible but if you have a way for a portal
to implement this I'm definitely interested.
I'd think the best way to design the API will be to first define a
generic
Portlet API which require the Portlet to output a completel
-Original Message-
From: Raphael Luta [mailto:[EMAIL PROTECTED]]
Sent: Samstag, 4. November 2000 13:15
To: JetSpeed
Subject: Re: Portlet API
- this may create problems with form handling because the
portal *needs*
to
make sure there are no variable name
nt targets to which the parameters would get posted ?
I'd think the best way to design the API will be to first define a
generic
Portlet API which require the Portlet to output a completely rendered
content, and then create a sub-interface XMLPortlet (or DataPortlet or
whatever) that wou
"Schwarz, Marcus" wrote:
- Locator provides methods to determine the current
location of a user's
device, e.g. longitude/latitude, country, state, city, ZIP code.
I don't think hooks should exist in a generic portlet API to
cater for this.
Too biased towards mobi
[EMAIL PROTECTED] wrote:
I completely agree with this drawing (if I read it correctly that is):
in your portlet API view, is the Portlet responsible for rendering its
output in the device format or is it handled by the portal framework ?
if the Portlet does not do the rendering, what does
-Original Message-
From: Raphael Luta [mailto:[EMAIL PROTECTED]]
Sent: Freitag, 3. November 2000 00:53
To: JetSpeed
Subject: Re: Portlet API
"Schwarz, Marcus" wrote:
- Locator provides methods to determine the current
location of a user's
d
(Seems this mail did not get delivered, I hope you don't receive it twice)
It's good to see such a positive reaction on my first note about the
need for a standard Portlet API and that such a live discussion started.
I guess we should go into more detail now. The figure below shows a
portal
[EMAIL PROTECTED] wrote:
(Seems this mail did not get delivered, I hope you don't receive it twice)
It's good to see such a positive reaction on my first note about the
need for a standard Portlet API and that such a live discussion started.
Great, I don't have to write this anymore
[EMAIL PROTECTED] wrote:
Same here since we would not be working on top of Turbine, but be using
Cocoon2 instead. I'm not sure whether a application neutral Portal API would
be a feasible thing, at least a common feature list should be possible.
I think an application neutral Portal API
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
[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...
Raphael Luta wrote:
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.
The browser detection of Cocoon
Raphael Luta wrote:
My point is that you actually don't have to use all the
features offered
by a browser, just stick to standard stuff. Used any blink
tags lately ?
:)
Blink? Huh? :-)
You're right but unfortunately sometimes customers want all the latest stuff
possible with IE, and
After working on a portal project for a while with my team, I'd
like to share some of our ideas.
We see a big need for a standard Portlet API for Java that enables
application developers to implement portlets that are independent
of the underlying infrastructure. The Portlet API
78 matches
Mail list logo
