portlet spec question: "naked" portlet response

["Glenn R. Golden" <gg...@umich.edu>]

This is a question of the portlet spec, really.

I have portlets that place in their little part of the portal page one 
or more iframes in a layout.  This lets a single portlet have multiple 
independent regions.  These iframes get their src from the portlet in 
different modes.

I've implemented this in Jetspeed using a variation of the "content" 
template, which goes through the portal engine to the portlet but 
leaves off all the portal engine decorations (navigation, etc).  What 
comes out is the naked portlet response wrapped enough to form an HTML 
document.

While moving this design to the portlet spec, I realized that this is 
really Jetspeed specific, and I'm wondering how to do this using only 
the portlet standards.

Putting out the iframe layout should not be a problem, although the 
current portlet spec (PLT.B "Markup Fragments") prohibits the use of 
iframe in portlet output.  Can anyone comment as to why this is a 
problem for portlet, or if this is a mistake in the document (the other 
prohibited elements would be a problem for a fragment)?

The iframe needs to point back at the portlet for it's content.  Since 
the portlet needs to respond, the request must go through the portal 
engine, since it's the one processing URL requests and it's the one 
owning the portal container who owns the portlet.

A similar need is there if the portal engine allows portlets to be 
"floated" to new windows of their own, although in that case the portal 
engine may still decorate the new window in some way.

So how might this work? Does anyone see a way that this could be 
portlet spec standard, and not rely upon a particular portal engine?

Thanks,

- Glenn

Glenn R. Golden  CHEF Architect
System Research Programmer III
School of Information + Media Union @ University of Michigan
ggolden@umich.edu

Re: portlet spec question: "naked" portlet response

[Santiago Gala <sg...@hisitech.com>]

El lunes, 20 octu, 2003, a las 08:32 Europe/Madrid, Stefan Hepper 
escribió:

> Hi Glenn,
> the must not in the spec is an error, it should have been "should not".
>
> The reason for this is that with the use of iframes you kind of tunnel 
> the portlet api and instead using the portlet api include directly 
> applications. This breaks the portal model and is therefore not 
> recommended. You can do this to include legacy applications, but it is 
> not a recommended portlet programming model.
>

Agreed.

> Stefan
>
> Glenn R. Golden wrote:
>
>> This is a question of the portlet spec, really.
>> I have portlets that place in their little part of the portal page 
>> one or more iframes in a layout.  This lets a single portlet have 
>> multiple independent regions.  These iframes get their src from the 
>> portlet in different modes.
>> I've implemented this in Jetspeed using a variation of the "content" 
>> template, which goes through the portal engine to the portlet but 
>> leaves off all the portal engine decorations (navigation, etc).  What 
>> comes out is the naked portlet response wrapped enough to form an 
>> HTML document.
>> While moving this design to the portlet spec, I realized that this is 
>> really Jetspeed specific, and I'm wondering how to do this using only 
>> the portlet standards.

This can be done at the portal level. It impacts both in the aggregator 
and URL manager modules. And it has to cache the  portlet results for 
the "special" URL, but this is required by the spec already to a 
certain degree.

I.e. an aggregator which would post-process the output of portlets to 
have both a main page with the iframe tags and a "special" URL 
consisting in a decoration of the portlet contents to make it a HTML 
page.

The portlet will not notice it is running in such a "funny" portal. Not 
that I like it, but this could go into jetspeed-2 eventually.


>> Putting out the iframe layout should not be a problem, although the 
>> current portlet spec (PLT.B "Markup Fragments") prohibits the use of 
>> iframe in portlet output.  Can anyone comment as to why this is a 
>> problem for portlet, or if this is a mistake in the document (the 
>> other prohibited elements would be a problem for a fragment)?
>> The iframe needs to point back at the portlet for it's content.  
>> Since the portlet needs to respond, the request must go through the 
>> portal engine, since it's the one processing URL requests and it's 
>> the one owning the portal container who owns the portlet.

iframe should not be in the portlet output. Rather, it should be the 
result of a special decorator handling the portlet. At least, this is 
how I see it.

Let's built on top of the portlet life cycle of render and action.

>> A similar need is there if the portal engine allows portlets to be 
>> "floated" to new windows of their own, although in that case the 
>> portal engine may still decorate the new window in some way.
>> So how might this work? Does anyone see a way that this could be 
>> portlet spec standard, and not rely upon a particular portal engine?
>> Thanks,
>> - Glenn
>> Glenn R. Golden  CHEF Architect
>> System Research Programmer III
>> School of Information + Media Union @ University of Michigan
>> ggolden@umich.edu

Re: portlet spec question: "naked" portlet response

[Stefan Hepper <st...@hursley.ibm.com>]

Hi Glenn,
the must not in the spec is an error, it should have been "should not".

The reason for this is that with the use of iframes you kind of tunnel 
the portlet api and instead using the portlet api include directly 
applications. This breaks the portal model and is therefore not 
recommended. You can do this to include legacy applications, but it is 
not a recommended portlet programming model.

Stefan

Glenn R. Golden wrote:

> This is a question of the portlet spec, really.
> 
> I have portlets that place in their little part of the portal page one 
> or more iframes in a layout.  This lets a single portlet have multiple 
> independent regions.  These iframes get their src from the portlet in 
> different modes.
> 
> I've implemented this in Jetspeed using a variation of the "content" 
> template, which goes through the portal engine to the portlet but leaves 
> off all the portal engine decorations (navigation, etc).  What comes out 
> is the naked portlet response wrapped enough to form an HTML document.
> 
> While moving this design to the portlet spec, I realized that this is 
> really Jetspeed specific, and I'm wondering how to do this using only 
> the portlet standards.
> 
> Putting out the iframe layout should not be a problem, although the 
> current portlet spec (PLT.B "Markup Fragments") prohibits the use of 
> iframe in portlet output.  Can anyone comment as to why this is a 
> problem for portlet, or if this is a mistake in the document (the other 
> prohibited elements would be a problem for a fragment)?
> 
> The iframe needs to point back at the portlet for it's content.  Since 
> the portlet needs to respond, the request must go through the portal 
> engine, since it's the one processing URL requests and it's the one 
> owning the portal container who owns the portlet.
> 
> A similar need is there if the portal engine allows portlets to be 
> "floated" to new windows of their own, although in that case the portal 
> engine may still decorate the new window in some way.
> 
> So how might this work? Does anyone see a way that this could be portlet 
> spec standard, and not rely upon a particular portal engine?
> 
> Thanks,
> 
> - Glenn
> 
> Glenn R. Golden  CHEF Architect
> System Research Programmer III
> School of Information + Media Union @ University of Michigan
> ggolden@umich.edu
> 
>