You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Glenn Golden <gg...@umich.edu> on 2002/03/05 16:23:01 UTC
Jetspeed Proposal: iframe portlet control
Here is a proposal for Jetspeed. We (the CHEF team at U of M) need this in
our Jetspeed, and I'd like to develop it for Jetspeed proper. I'd like to
get your feedback, comments, and suggestions, and to find out if we can put
this into the product.
* * *
1.0 Goals:
To select any portlet to be placed into an iframe in the portal page. This
allows the portlet:
1.1 page size control with scrolling
Users would be able to specify the size of the portlet on the page, probably
just the height, as the layout figures the width. If the portlet content is
larger than the footprint, scroll bars would appear to allow the portlet to
be scrolled independently of the rest of the portal page.
1.2 independent updating, scriptable
Each portlet in an iframe could have its contents refreshed without having
the rest of the page refreshed. This would happen if the user pressed a
link or a form submit within the portlet content, or if javascript in the
portal page caused the iframe to refresh (usually by changing the src=
attribute of the iframe). Nothing else on the page would change when a
portlet refreshes. Multiple portlets in iframes on the same portal page
could refresh concurrently, independently.
1.3 directed form processing
When a form from an iframe'ed portlet is submitted, it is sent to a URL
which causes just the portlet to be displayed back into the iframe. For
Velocity portlets, this means that just that one addressed portlet would get
a change to process the form data. This focuses the submit to the one
portlet, which is usually what we want.
When an AbstractPortlet is placed in an iframe, it would be using real
Turbine actions encoded into the form submit, which are already focused on
the portlet's action class.
* * *
2.0 Details
2.1 Title Bar in Portal, Portlet in iframe
When a portlet is placed into an iframe, the portlet title bar and controls
are left in the portal page, with the iframe just below and sized to fit the
width of the portlet's footprint on the screen.
2.2 User's select, Mix and match
Users would be able to mix portlets on a portal page that are directly on
the page with those that are in iframes. Any portlet can be placed into an
iframe.
2.3 Portlet Content URL
To support the iframe's addressing of a single portlet, a special URL if
formed to address the portlet content.
* * *
3.0 Implementation
3.1 Portlet Content
I distinguish between the portlet's full display, including the
PortletControl, and just the display from the portlet itself, calling the
later the portlet content. To get a display of just the portlet content, a
new screen is added to Jetspeed called "Content". This consists of a screen
template, Content.vm, and a page layout template, also called Content.vm.
3.1.1 The layout template achieves the goal of delivering just the screen
without any navigation:
<html>
<head>
<base href="$clink.External" />
<link href="$clink.setURI("css/default.css").Absolute" type="text/css"
rel="stylesheet" />
</head>
<body bgcolor="#ffffff">
$screen_placeholder
</body>
</html>
3.1.2 The screen template achieves the goal of delivering just the portlet
content, not the whole page, not the portlet control:
#if ($data.Portlet)
$jetspeed.getPortletContent($data.Portlet)
#else
<p>Portlet missing</p>
#end
Notice that there is a new method added to the JetspeedTool:
getPortletContent(). This is just like getPortlet(), except that when the
named portlet is found, getPortlet() points at the control, and
getPortletContent() points at the portlet within the control.
3.1.3 Here's the code to add to JetspeedTool:
/**
* Return the content of a named portlet, without the controller. This
portlet is sought in
* the current PSML resource.
*
* @param name the name of the portlet to render
* @return the rendered content of the portlet
*/
public ConcreteElement getPortletContent(String name)
{
ConcreteElement result = null;
Portlet found = null;
Stack sets = new Stack();
sets.push(rundata.getProfile().getRootSet());
while ((sets.size() > 0) && (found==null))
{
PortletSet set = (PortletSet)sets.pop();
if (set.getName().equals(name))
{
found = set;
}
else
{
Enumeration en = set.getPortlets();
while((found==null) && en.hasMoreElements())
{
Portlet p = (Portlet)en.nextElement();
// unstack the controls to find the real PortletSets
Portlet real = p;
while (real instanceof PortletControl)
{
real = ((PortletControl)p).getPortlet();
}
if (real instanceof PortletSet)
{
// we'll explore this set afterwards
sets.push(real);
}
else if (p.getName().equals(name))
{
found = real;
}
}
}
}
if (found!=null)
{
result = found.getContent(rundata);
}
if (result==null)
{
//the customizer already streamed its content, return a stub
result = new ConcreteElement();
}
return result;
}
3.1.4 An action called Content is available to select the new content
screen for a request:
public class Content extends Action
{
public void doPerform(RunData data)
{
// pick the "Content" screen, and matching page layout
jdata.setScreenTemplate("Content");
}
}
3.1.5 URLs
To invoke this new screen, the URL looks like this:
/jetspeed/portal/template/Content/portlet/<portlet name>
or
/jetspeed/portal/template/Content?portlet=<portlet name>
or, using the action:
/jetspeed/portal?action=Content&portlet=<portlet name>
3.1.6 Portlet Identifier
The portlet name is used to find the portlet, much as it is used in the
jetspeed tool's getPortlet. I see that this is being extended with
"&container=". Whatever we decide on to uniquely identify and find a
portlet within a portal page, we need to use here as well, and the above
URL's would be extended, extending the portlet=<name> with the additional
information.
3.1.7 Form Action
Portlets in an iframe need to specify a different form action, to make sure
that when the form is submitted, only the portlet content comes back. The
action url is the same as those in 3.1.5 above. In a velocity template,
this can be achieved with:
$jlink.setPortlet("$!data.Portlet")
giving us the url of the form:
/jetspeed/portal/template/Content/portlet/<portlet name>
Note, if additional information is needed to identify the portlet, this
additional information needs to be placed into $data so it can be used in
the link, or, better yet, a new method could be added to $jlink (or
setPortlet() updated?) to handle the properly id a portlet.
If the portlet is in the portal page directly, not in an iframe, the above
link works, with the /portlet/ being ignored. Actually, the url becomes
/jetspeed/portal/template/Home/portlet/null.
We could enhance the JetspeedTemplateLink.setPortlet() call to do nothing if
the portlet is null.
Note that if the portlet is in an iframe, the form submit request will be
given only to that portlet, achieving our direct form processing goal.
3.2 Portlet Control
To place a portlet into an iframe, we can set a new portlet control for the
portlet. This new control, the iFramePortletControl, takes care of placing
the portlet into the iframe. Only portlets with this control would be
placed into iframes; other portlets would be placed directly into the portal
page.
Another option would be to have an optional parameter to any portlet, the
"iframe" boolean, which all the portlet controls would look for. In this
case. This may be easier to implement in the customizer, and give more
flexibility. For this proposal, I describe the iFramePortletControl
approach.
3.2.1 iFramePortletControl
This is a velocity based portlet control, using an extension of the
VelocityPortletControl to provide more context. The iframe.vm file is a
copy of the jetspeed.vm file, with one change: Instead of placing the
portlet content with:
$!portlet.getContent($data)
It places the iframe, in the same place, with:
<iframe
name="$portlet.Name"
width="100%"
frameborder="0"
marginwidth="0"
marginheight="0"
scrolling="auto"
align="middle"
src="$iframeSrc">
</iframe>
Note: rather than making a copy of jetspeed.vm as iframe.vm and modifying
it, I'd like to use the one jetspeed.vm, enhanced to know to place iframe or
not. This plays into the other approach that makes all the controls iframe
aware.
The $iframeSrc is made much like the actions in VelocityPortletControl by
the extended class (see section 3.2.3).
3.2.2 iFramePortletControl registry entry
The entry for the new portlet control is:
<portlet-control-entry name="iFramePortletControl" hidden="true">
<classname>umich.chef.util.VelocityPortletIFrameControl</classname>
<parameter name="theme" value="iframe.vm"/>
<meta-info>
<title>iFramePortletControl</title>
</meta-info>
<media-type ref="wml"/>
<media-type ref="html"/>
</portlet-control-entry>
Note: the class is currently in my "umich.chef.util" package, but we would
want to place it into a jetspeed package.
3.2.3 VelocityPortletIFrameControl
The extension to VelocityPortletControl to add the $iframeSrc to the context
is:
public class VelocityPortletIFrameControl extends VelocityPortletControl
{
/**
* This method allows subclasses of the VelocityPortletControl
* to populate the context of this control before rendering by
* the template engine.
*
* @param rundata the RunData object for this request
* @param context the Context used by the template
*/
public void buildContext( RunData rundata, Context context )
{
Portlet portlet = getPortlet();
String container = "na";
if ( portlet.getPortletConfig().getPortletSet() != null)
{
container =
portlet.getPortletConfig().getPortletSet().getName();
}
String iframeSrc = new RelativeDynamicURI( rundata )
.addQueryData("action", "Content" )
.addQueryData("portlet", portlet.getName() )
.addQueryData("container", container )
.toString();
context.put("iframeSrc", iframeSrc);
}
}
Note: This continues the container work, and would need to be updated to
whatever methods we are using to id a portlet.
3.3 Customization
The customizers need to be modified to allow the user the choice of the
control for the portlet. Or, if we take the other approach, the user needs
to be able to indicate iframe or not, and some iframe parameters (such as
height). I have not done this, nor do I know much about how this works
(yet).
For now, to make a portlet be in an iframe, the .psml needs to be hand
edited:
<entry parent="whoever">
<control name = "iFramePortletControl"/>
</entry>
4.0 Summary and Conclusion
I'd like to incorporate this work into the 1.3a3 jetspeed. This would
involve:
-update to the JetspeedTool (getPortletContent())
-addition of the Content screen and layout templates
-addition of the Content action, placed into the jetspeed package
org.apache.jetspeed.modules.actions.controls
-(possible) update to $jlink.setPortlet() to have it take care of the
current portlet unique naming scheme, or (possibly) a new entry
-addition of the iFramePortletControl to the controls.xreg
-addition of the iframe.vm
-addition of the VelocityPortletIFrameControl class, placed in the package
org.apache.jetspeed.portal.controls
-or- some changes to the set of controls to recognize a common set of
portlet parameters for iframe
4.1 Decisions
Do we want this in Jetspeed?
Are there improvements to these details that better fit the jetspeed code
and intentions?
Do we want a single portlet control, or updates to them all?
How are we going to identify a portlet within a portal page? What code will
support forming this id and finding?
How to change the customizers to support portlet control choice?
Should we surface more iframe control to the user, such as height?
Should we make the iframe parameters different (bigger height) when the
portlet is maximized?
* * *
I have preliminary versions of this coded and working. I am happy to make
changes based on the group's feedback and decisions. I can then email files
ready for checkin to a committer who would work with me on this.
Thanks for your time and attention.
- Glenn
--------------------------------------------
Glenn R. Golden, Systems Research Programmer
University of Michigan School of Information
<ma...@umich.edu> ggolden@umich.edu 734-615-1419
<http://www-personal.si.umich.edu/~ggolden/>
http://www-personal.si.umich.edu/~ggolden/
--------------------------------------------
Re: Jetspeed Proposal: iframe portlet control
Posted by Santiago Gala <sg...@hisitech.com>.
Glenn Golden wrote:
>Here is a proposal for Jetspeed. We (the CHEF team at U of M) need this in
>our Jetspeed, and I'd like to develop it for Jetspeed proper. I'd like to
>get your feedback, comments, and suggestions, and to find out if we can put
>this into the product.
>
>* * *
>
>1.0 Goals:
>
>To select any portlet to be placed into an iframe in the portal page. This
>allows the portlet:
>
>1.1 page size control with scrolling
>
>Users would be able to specify the size of the portlet on the page, probably
>just the height, as the layout figures the width. If the portlet content is
>larger than the footprint, scroll bars would appear to allow the portlet to
>be scrolled independently of the rest of the portal page.
>
>1.2 independent updating, scriptable
>
>Each portlet in an iframe could have its contents refreshed without having
>the rest of the page refreshed. This would happen if the user pressed a
>link or a form submit within the portlet content, or if javascript in the
>portal page caused the iframe to refresh (usually by changing the src=
>attribute of the iframe). Nothing else on the page would change when a
>portlet refreshes. Multiple portlets in iframes on the same portal page
>could refresh concurrently, independently.
>
>1.3 directed form processing
>
>When a form from an iframe'ed portlet is submitted, it is sent to a URL
>which causes just the portlet to be displayed back into the iframe. For
>Velocity portlets, this means that just that one addressed portlet would get
>a change to process the form data. This focuses the submit to the one
>portlet, which is usually what we want.
>
>When an AbstractPortlet is placed in an iframe, it would be using real
>Turbine actions encoded into the form submit, which are already focused on
>the portlet's action class.
>
>* * *
>
>2.0 Details
>
>2.1 Title Bar in Portal, Portlet in iframe
>
>When a portlet is placed into an iframe, the portlet title bar and controls
>are left in the portal page, with the iframe just below and sized to fit the
>width of the portlet's footprint on the screen.
>
>2.2 User's select, Mix and match
>
>Users would be able to mix portlets on a portal page that are directly on
>the page with those that are in iframes. Any portlet can be placed into an
>iframe.
>
>2.3 Portlet Content URL
>
>To support the iframe's addressing of a single portlet, a special URL if
>formed to address the portlet content.
>
>* * *
>
>3.0 Implementation
>
>3.1 Portlet Content
>
>I distinguish between the portlet's full display, including the
>PortletControl, and just the display from the portlet itself, calling the
>later the portlet content. To get a display of just the portlet content, a
>new screen is added to Jetspeed called "Content". This consists of a screen
>template, Content.vm, and a page layout template, also called Content.vm.
>
Content looks as a confusing name. I would prefer if both the screen and
the layout are named "clear", instead of content. We used to have clear
screens before (in 1.3a1), to mean screens where there were no
navigation, control, etc.
Otherwise (see my small comment on jlink below), I agree with the proposal.
I'm beeing careful about naming, since the names stand a lot on the way
we understand code, and getting good understanding of source code is
needed if we are going to keep improving jetspeed. If anyone has a
better suggestion on naming, please stand up!
>
>3.1.1 The layout template achieves the goal of delivering just the screen
>without any navigation:
>
><html>
> <head>
> <base href="$clink.External" />
> <link href="$clink.setURI("css/default.css").Absolute" type="text/css"
>rel="stylesheet" />
> </head>
> <body bgcolor="#ffffff">
> $screen_placeholder
> </body>
></html>
>
>3.1.2 The screen template achieves the goal of delivering just the portlet
>content, not the whole page, not the portlet control:
>
>#if ($data.Portlet)
> $jetspeed.getPortletContent($data.Portlet)
>#else
> <p>Portlet missing</p>
>#end
>
>Notice that there is a new method added to the JetspeedTool:
>getPortletContent(). This is just like getPortlet(), except that when the
>named portlet is found, getPortlet() points at the control, and
>getPortletContent() points at the portlet within the control.
>
>3.1.3 Here's the code to add to JetspeedTool:
>
> /**
> * Return the content of a named portlet, without the controller. This
>portlet is sought in
> * the current PSML resource.
> *
> * @param name the name of the portlet to render
> * @return the rendered content of the portlet
> */
> public ConcreteElement getPortletContent(String name)
> {
> ConcreteElement result = null;
> Portlet found = null;
> Stack sets = new Stack();
> sets.push(rundata.getProfile().getRootSet());
>
> while ((sets.size() > 0) && (found==null))
> {
> PortletSet set = (PortletSet)sets.pop();
>
> if (set.getName().equals(name))
> {
> found = set;
> }
> else
> {
> Enumeration en = set.getPortlets();
> while((found==null) && en.hasMoreElements())
> {
> Portlet p = (Portlet)en.nextElement();
>
> // unstack the controls to find the real PortletSets
> Portlet real = p;
> while (real instanceof PortletControl)
> {
> real = ((PortletControl)p).getPortlet();
> }
>
> if (real instanceof PortletSet)
> {
> // we'll explore this set afterwards
> sets.push(real);
> }
> else if (p.getName().equals(name))
> {
> found = real;
> }
> }
> }
> }
>
> if (found!=null)
> {
> result = found.getContent(rundata);
> }
>
> if (result==null)
> {
> //the customizer already streamed its content, return a stub
> result = new ConcreteElement();
> }
>
> return result;
> }
>
>3.1.4 An action called Content is available to select the new content
>screen for a request:
>
>public class Content extends Action
>{
> public void doPerform(RunData data)
> {
> // pick the "Content" screen, and matching page layout
> jdata.setScreenTemplate("Content");
> }
>}
>
>3.1.5 URLs
>
>To invoke this new screen, the URL looks like this:
>
>/jetspeed/portal/template/Content/portlet/<portlet name>
>
>or
>
>/jetspeed/portal/template/Content?portlet=<portlet name>
>
>or, using the action:
>
>/jetspeed/portal?action=Content&portlet=<portlet name>
>
>
>3.1.6 Portlet Identifier
>
>The portlet name is used to find the portlet, much as it is used in the
>jetspeed tool's getPortlet. I see that this is being extended with
>"&container=". Whatever we decide on to uniquely identify and find a
>portlet within a portal page, we need to use here as well, and the above
>URL's would be extended, extending the portlet=<name> with the additional
>information.
>
>3.1.7 Form Action
>
>Portlets in an iframe need to specify a different form action, to make sure
>that when the form is submitted, only the portlet content comes back. The
>action url is the same as those in 3.1.5 above. In a velocity template,
>this can be achieved with:
>
>$jlink.setPortlet("$!data.Portlet")
>
>
I have just deprecated setPortlet, due to confusing naming when we added
void setPortlet( portlet) to JetspeedTemplateLink. I proposed
forPortlet() instead.
Thus, your example would be:
$jlink.forPortlet("$!data.Portlet")
which looks cleaner to me. Is is read as "give me the jetspeed link for
portlet $!data.Portlet"
>
>giving us the url of the form:
>
>/jetspeed/portal/template/Content/portlet/<portlet name>
>
>Note, if additional information is needed to identify the portlet, this
>additional information needs to be placed into $data so it can be used in
>the link, or, better yet, a new method could be added to $jlink (or
>setPortlet() updated?) to handle the properly id a portlet.
>
>If the portlet is in the portal page directly, not in an iframe, the above
>link works, with the /portlet/ being ignored. Actually, the url becomes
>
>/jetspeed/portal/template/Home/portlet/null.
>
>We could enhance the JetspeedTemplateLink.setPortlet() call to do nothing if
>the portlet is null.
>
>Note that if the portlet is in an iframe, the form submit request will be
>given only to that portlet, achieving our direct form processing goal.
>
>3.2 Portlet Control
>
>To place a portlet into an iframe, we can set a new portlet control for the
>portlet. This new control, the iFramePortletControl, takes care of placing
>the portlet into the iframe. Only portlets with this control would be
>placed into iframes; other portlets would be placed directly into the portal
>page.
>
>Another option would be to have an optional parameter to any portlet, the
>"iframe" boolean, which all the portlet controls would look for. In this
>case. This may be easier to implement in the customizer, and give more
>flexibility. For this proposal, I describe the iFramePortletControl
>approach.
>
>
>
>3.2.1 iFramePortletControl
>
>This is a velocity based portlet control, using an extension of the
>VelocityPortletControl to provide more context. The iframe.vm file is a
>copy of the jetspeed.vm file, with one change: Instead of placing the
>portlet content with:
>
>$!portlet.getContent($data)
>
>It places the iframe, in the same place, with:
>
> <iframe
> name="$portlet.Name"
> width="100%"
> frameborder="0"
> marginwidth="0"
> marginheight="0"
> scrolling="auto"
> align="middle"
> src="$iframeSrc">
> </iframe>
>
>Note: rather than making a copy of jetspeed.vm as iframe.vm and modifying
>it, I'd like to use the one jetspeed.vm, enhanced to know to place iframe or
>not. This plays into the other approach that makes all the controls iframe
>aware.
>
>The $iframeSrc is made much like the actions in VelocityPortletControl by
>the extended class (see section 3.2.3).
>
>3.2.2 iFramePortletControl registry entry
>
>The entry for the new portlet control is:
>
> <portlet-control-entry name="iFramePortletControl" hidden="true">
> <classname>umich.chef.util.VelocityPortletIFrameControl</classname>
> <parameter name="theme" value="iframe.vm"/>
> <meta-info>
> <title>iFramePortletControl</title>
> </meta-info>
> <media-type ref="wml"/>
> <media-type ref="html"/>
> </portlet-control-entry>
>
>Note: the class is currently in my "umich.chef.util" package, but we would
>want to place it into a jetspeed package.
>
>3.2.3 VelocityPortletIFrameControl
>
>The extension to VelocityPortletControl to add the $iframeSrc to the context
>is:
>
>public class VelocityPortletIFrameControl extends VelocityPortletControl
>{
> /**
> * This method allows subclasses of the VelocityPortletControl
> * to populate the context of this control before rendering by
> * the template engine.
> *
> * @param rundata the RunData object for this request
> * @param context the Context used by the template
> */
> public void buildContext( RunData rundata, Context context )
> {
> Portlet portlet = getPortlet();
>
> String container = "na";
> if ( portlet.getPortletConfig().getPortletSet() != null)
> {
> container =
>portlet.getPortletConfig().getPortletSet().getName();
> }
>
> String iframeSrc = new RelativeDynamicURI( rundata )
> .addQueryData("action", "Content" )
> .addQueryData("portlet", portlet.getName() )
> .addQueryData("container", container )
> .toString();
> context.put("iframeSrc", iframeSrc);
> }
>}
>
>Note: This continues the container work, and would need to be updated to
>whatever methods we are using to id a portlet.
>
>3.3 Customization
>
>The customizers need to be modified to allow the user the choice of the
>control for the portlet. Or, if we take the other approach, the user needs
>to be able to indicate iframe or not, and some iframe parameters (such as
>height). I have not done this, nor do I know much about how this works
>(yet).
>
>For now, to make a portlet be in an iframe, the .psml needs to be hand
>edited:
>
> <entry parent="whoever">
> <control name = "iFramePortletControl"/>
> </entry>
>
>4.0 Summary and Conclusion
>
>I'd like to incorporate this work into the 1.3a3 jetspeed. This would
>involve:
>
>-update to the JetspeedTool (getPortletContent())
>-addition of the Content screen and layout templates
>-addition of the Content action, placed into the jetspeed package
>org.apache.jetspeed.modules.actions.controls
>-(possible) update to $jlink.setPortlet() to have it take care of the
>current portlet unique naming scheme, or (possibly) a new entry
>-addition of the iFramePortletControl to the controls.xreg
>-addition of the iframe.vm
>-addition of the VelocityPortletIFrameControl class, placed in the package
>org.apache.jetspeed.portal.controls
>-or- some changes to the set of controls to recognize a common set of
>portlet parameters for iframe
>
>
>4.1 Decisions
>
>Do we want this in Jetspeed?
>
Why not? +1
>
>Are there improvements to these details that better fit the jetspeed code
>and intentions?
>
I pointed small comments up, mostly terminology.
>
>Do we want a single portlet control, or updates to them all?
>
I'm not sure about this one. We could have a property called "iframe",
meaning that you want the portlet to be rendered in a separate (inline)
frame. This could be taken as a hint to the portlet container. If the
media allows for iframes, then iframe you get. If not, you could get a
pop-up window connected through javascript with the main window (your
get frame, but not inline) or current inline behaviour (no frame, but
inline content). That would depend on implementation templates and
client capabilities. Opinions?
>
>How are we going to identify a portlet within a portal page? What code will
>support forming this id and finding?
>
>
A portlet is a relatively long lived object. It can (ideally) be
rendered in several places in the same psml, and in different places for
different users.
A portlet can be referred in two different ways:
- "positional id", like I want portlet "default.1.2.1" which means the
first portlet of the second portletset of the first portletset in the
default.psml resource. This breaks when the user rearranges (customizes)
the resources.
- "absolute id". The name is independent of its position in psml. It can
be achieved in two forms: the entry name (or id) itself, given in the
registry for all instances and controlled by the site admin, or some
metainfo name (or id), different per instance and controlled by the psml
writer/customizer. It would be carried with the PortletConfig.
Some kind of metainfo id could be used for most applications. It could
be generated as the PSML is parsed, or just filled in by hand (maybe
this could be a good way to bootstrap it). Even if they are hand-written
in PSML and are not guaranteed unique per psml, they could be useful to
test the concepts.
>
>How to change the customizers to support portlet control choice?
>
>Should we surface more iframe control to the user, such as height?
>
>Should we make the iframe parameters different (bigger height) when the
>portlet is maximized?
>
>* * *
>
>I have preliminary versions of this coded and working. I am happy to make
>changes based on the group's feedback and decisions. I can then email files
>ready for checkin to a committer who would work with me on this.
>
>Thanks for your time and attention.
>
>- Glenn
>
>--------------------------------------------
>Glenn R. Golden, Systems Research Programmer
>University of Michigan School of Information
> <ma...@umich.edu> ggolden@umich.edu 734-615-1419
> <http://www-personal.si.umich.edu/~ggolden/>
>http://www-personal.si.umich.edu/~ggolden/
>--------------------------------------------
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jetspeed Proposal: iframe portlet control
Posted by Bill Barnhill <wb...@twcny.rr.com>.
Sounds good. It was the direction I was heading with my iframe portlet, but
was bogged down with work and working on skinned tabs. I think it would be
nice to maintain the user's option of iframing the content from a url
without hacing to go through an Html portlet.
I'd love another 8 hours in the day, but with just getting married, and ten
hours for work each day, time is short. Should be more available now
though, which is good.
----- Original Message -----
From: "David Sean Taylor" <da...@bluesunrise.com>
To: "'Jetspeed Developers List'" <je...@jakarta.apache.org>
Sent: Tuesday, March 05, 2002 1:54 PM
Subject: RE: Jetspeed Proposal: iframe portlet control
> Good proposal.
>
> I think that this overall feature should be supported throughout the
> project, and not only with iframes, and with different media types.
>
> I like the idea of randomly accessing content, whether it's a portlet, a
> portlet with its control, or a collection of portlets. In order for this
> to work, we need to have unique ids support. Paul and I have been
> discussing this for a while now, and he just committed the start of the
> portlet id implementation. Its not complete. We still need to work out:
>
> - a conversion utility to take existing psml files and ensure that a
> unique id is added to each and every 'entry' and 'portlets' element.
> - modify psml.xsd to mandate an id entry for 'portlets' and 'entry'
> change:
> <attribute name="id" type="string" minOccurs="1"/>
> to:
> <attribute name="id" type="string" use="required"/>
> - a unique value generator (Turbine's has been deprecated)
> - deprecate all pane and portlet references, and replace them with a new
> portlet/portletset reference mechanism, integrating with tools (jlink)
>
> Think about making the portlet id required. It means that old psml files
> will be incompatible until converted.
>
> I agree with Santiago, that we should all agree on a common naming
> convention. I like 'Content' better than 'Clear'...what about
> 'PortletElement'?
>
> The default content, an entire portal page is addressed by
> /jetspeed/portal.
> It gets the default layout/template.
>
> What about "/template/PortalElement/peid/42" where
> peid - represents portal element id (see above)
> PEID can represent either a portlet entry or portlet set.
>
> Then JetspeedTool would have a 'getPortalElement' method etc.
> Anyway, that's my vote on the naming.
>
> My vote is +1 on this, as long as we make sure it supports other media
> types and constructs as well as IFrames.
>
> Im now going to look into continuing what Paul started on using unique
> ids across the system.
>
>
> > 4.1 Decisions
> >
> > Do we want this in Jetspeed?
>
> +1
>
> >
> > Are there improvements to these details that better fit the
> > jetspeed code and intentions?
>
> See above.
>
> >
> > Do we want a single portlet control, or updates to them all?
>
> I like the optional "iframe" attribute on all controls.
> This gives the most flexibility.
>
> >
> > How are we going to identify a portlet within a portal page?
>
> See above.
>
> > What code will support forming this id and finding?
>
> We're still working that out.
>
> >
> > How to change the customizers to support portlet control choice?
>
> Do you mean the 'Iframe' option? Not sure if I understand this question.
>
> >
> > Should we surface more iframe control to the user, such as height?
>
> Yes. Perhaps a more detailed design of Iframe customization would help.
>
> >
> > Should we make the iframe parameters different (bigger
> > height) when the portlet is maximized?
>
> Perhaps a more detailed design of Iframe customization would help.
>
> David
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Jetspeed Proposal: iframe portlet control
Posted by David Sean Taylor <da...@bluesunrise.com>.
> Santiago Gala wrote:
>
> > (...) quoting myself :(
>
>
> >
> > Random thought (take it with a cup of salt):
> >
> > A simple id generation algorithm: take the parent id, and
> append "." +
> > a max-sibling number from parent. Each portletset would
> store a number
> > that is the number of portlet ever contained inside (when a
> portlet is
> > removed, the number is *not* decremented, so it is not equal to the
> > sibling count). To guarantee it, when a portletset receives
> a portlet
> > with null id, it will generate one using this scheme and increment
> > max-siblings. When it receives a portlet with non-null id, it will
> > just increment max-siblings.
>
> (...)
>
> I see David has it half way committed, so forget about it for
> the moment.
>
> (...)
>
No, our emails are crossing. Please continue this conversation :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jetspeed Proposal: iframe portlet control
Posted by Santiago Gala <sg...@hisitech.com>.
Santiago Gala wrote:
> (...) quoting myself :(
>
> Random thought (take it with a cup of salt):
>
> A simple id generation algorithm: take the parent id, and append "." +
> a max-sibling number from parent. Each portletset would store a number
> that is the number of portlet ever contained inside (when a portlet is
> removed, the number is *not* decremented, so it is not equal to the
> sibling count). To guarantee it, when a portletset receives a portlet
> with null id, it will generate one using this scheme and increment
> max-siblings. When it receives a portlet with non-null id, it will
> just increment max-siblings.
(...)
I see David has it half way committed, so forget about it for the moment.
(...)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jetspeed Proposal: iframe portlet control
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>Santiago Gala wrote on Wednesday, March 06, 2002 8:49 AM:
>
>>It should be only unique per psml resource. Thus we can make this
>>conversion utility choose whichever convention we wish.
>>Including a deep
>>traversal with a counter incremented for each entry found, or
>>tree-like
>>namings, like I pointed with "positional id".
>>
>>Random thought (take it with a cup of salt):
>>
>>A simple id generation algorithm: take the parent id, and
>>append "." + a
>>max-sibling number from parent. Each portletset would store a number
>>that is the number of portlet ever contained inside (when a
>>portlet is
>>removed, the number is *not* decremented, so it is not equal to the
>>sibling count). To guarantee it, when a portletset receives a portlet
>>with null id, it will generate one using this scheme and increment
>>max-siblings. When it receives a portlet with non-null id, it
>>will just
>>increment max-siblings.
>>
>>The root portletset would get default.1 always (default
>>stands for the
>>psml name). The siblings would get default.1.[1..n], and so on.
>>
>>This has interesting properties:
>>
>>- If we save the psml, the ids get saved and later restored.
>>- If we don't, the original ids will be (re)generated on reload
>>- For unedited psml the ids reflect the page structure
>>- For edited psml the ids no longer reflect it, but they are unique
>>- if an entry gets deleted and a new one added, it will get a higher
>>number. The deleted entry will retain its id until garbage collected.
>>- if a portlets or a portletentry is moved up in the psml
>>hierarchy, it
>>will retain the old id. The same if a portlets or an entry is
>>moved down.
>>
>
>This is a good migration path.
>With your plan, a PSML-conversion utility is not necessary, although we
>can still provide one.
>The ids are generated 'on-the-fly', and unless someone customizes, the
>ids will never be saved back to PSML.
>Regardless, I will still modify all distributed PSML files to follow
>your id-scheme if everyone agrees on it this id-scheme....
>
>
>>(I'm not completely sure it guarantees uniqueness, but I would bet)
>>
>>On the other side, the length of ids can be a problem, and
>>the fact that
>>we need string manipulations to create them.
>>
>
>Why is this a problem?
>
Performance, as ids could get long (depending on depth of nesting).
String.equals() is way slower than int ==, unless Strings are
intern()ed, and this has problems also.
Also, for DB storage we would need to assume a maximal length.
We should study the issues of this on the clustering of portal VMs. I
think it will require session affinity or session replication to work.
But we need it anyhow.
>
>>To make this possible, we would have to migrate psml
>>management to the
>>mapping Castor generation, and use our own classes. This
>>would give us
>>more control on the classes, but it is a major work.
>>
>
>Im not sure if this is necessary. See my commits today.
>I believe we can add the id in the PortalToolkitService if not already
>there.
>
>The only remaining question I have is: Does anyone think its necessary
>to have unique ids across the portal server?
>
A psml name + a unique psml id is a resource unique id. It should be
unique WRT a given session (separate sessions from the same user will
have the same ids, including anonymous sessions as one user).
A session id + the above is a portal server unique id.
As long as everything is not stored or referenced beyond the session
scope, we should be safe.
This is mostly intuition. You (should) know I'm not a very formal
thinker, rather highly intuitive. I would welcome any issue or proof "a
contrario".
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Jetspeed Proposal: iframe portlet control
Posted by David Sean Taylor <da...@bluesunrise.com>.
Santiago Gala wrote on Wednesday, March 06, 2002 8:49 AM:
> It should be only unique per psml resource. Thus we can make this
> conversion utility choose whichever convention we wish.
> Including a deep
> traversal with a counter incremented for each entry found, or
> tree-like
> namings, like I pointed with "positional id".
>
> Random thought (take it with a cup of salt):
>
> A simple id generation algorithm: take the parent id, and
> append "." + a
> max-sibling number from parent. Each portletset would store a number
> that is the number of portlet ever contained inside (when a
> portlet is
> removed, the number is *not* decremented, so it is not equal to the
> sibling count). To guarantee it, when a portletset receives a portlet
> with null id, it will generate one using this scheme and increment
> max-siblings. When it receives a portlet with non-null id, it
> will just
> increment max-siblings.
>
> The root portletset would get default.1 always (default
> stands for the
> psml name). The siblings would get default.1.[1..n], and so on.
>
> This has interesting properties:
>
> - If we save the psml, the ids get saved and later restored.
> - If we don't, the original ids will be (re)generated on reload
> - For unedited psml the ids reflect the page structure
> - For edited psml the ids no longer reflect it, but they are unique
> - if an entry gets deleted and a new one added, it will get a higher
> number. The deleted entry will retain its id until garbage collected.
> - if a portlets or a portletentry is moved up in the psml
> hierarchy, it
> will retain the old id. The same if a portlets or an entry is
> moved down.
>
This is a good migration path.
With your plan, a PSML-conversion utility is not necessary, although we
can still provide one.
The ids are generated 'on-the-fly', and unless someone customizes, the
ids will never be saved back to PSML.
Regardless, I will still modify all distributed PSML files to follow
your id-scheme if everyone agrees on it this id-scheme....
> (I'm not completely sure it guarantees uniqueness, but I would bet)
>
> On the other side, the length of ids can be a problem, and
> the fact that
> we need string manipulations to create them.
Why is this a problem?
>
> To make this possible, we would have to migrate psml
> management to the
> mapping Castor generation, and use our own classes. This
> would give us
> more control on the classes, but it is a major work.
Im not sure if this is necessary. See my commits today.
I believe we can add the id in the PortalToolkitService if not already
there.
The only remaining question I have is: Does anyone think its necessary
to have unique ids across the portal server?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jetspeed Proposal: iframe portlet control
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>Good proposal.
>
>I think that this overall feature should be supported throughout the
>project, and not only with iframes, and with different media types.
>
>I like the idea of randomly accessing content, whether it's a portlet, a
>portlet with its control, or a collection of portlets. In order for this
>to work, we need to have unique ids support. Paul and I have been
>discussing this for a while now, and he just committed the start of the
>portlet id implementation. Its not complete. We still need to work out:
>
>- a conversion utility to take existing psml files and ensure that a
>unique id is added to each and every 'entry' and 'portlets' element.
>
It should be only unique per psml resource. Thus we can make this
conversion utility choose whichever convention we wish. Including a deep
traversal with a counter incremented for each entry found, or tree-like
namings, like I pointed with "positional id".
Random thought (take it with a cup of salt):
A simple id generation algorithm: take the parent id, and append "." + a
max-sibling number from parent. Each portletset would store a number
that is the number of portlet ever contained inside (when a portlet is
removed, the number is *not* decremented, so it is not equal to the
sibling count). To guarantee it, when a portletset receives a portlet
with null id, it will generate one using this scheme and increment
max-siblings. When it receives a portlet with non-null id, it will just
increment max-siblings.
The root portletset would get default.1 always (default stands for the
psml name). The siblings would get default.1.[1..n], and so on.
This has interesting properties:
- If we save the psml, the ids get saved and later restored.
- If we don't, the original ids will be (re)generated on reload
- For unedited psml the ids reflect the page structure
- For edited psml the ids no longer reflect it, but they are unique
- if an entry gets deleted and a new one added, it will get a higher
number. The deleted entry will retain its id until garbage collected.
- if a portlets or a portletentry is moved up in the psml hierarchy, it
will retain the old id. The same if a portlets or an entry is moved down.
(I'm not completely sure it guarantees uniqueness, but I would bet)
On the other side, the length of ids can be a problem, and the fact that
we need string manipulations to create them.
To make this possible, we would have to migrate psml management to the
mapping Castor generation, and use our own classes. This would give us
more control on the classes, but it is a major work.
>
>- modify psml.xsd to mandate an id entry for 'portlets' and 'entry'
> change:
> <attribute name="id" type="string" minOccurs="1"/>
> to:
> <attribute name="id" type="string" use="required"/>
>
Possible alternative (more work, as said above): to switch to a
psml-mapping.xml Castor marshalling. In this way we would have more
control on attribute handling.
>
>- a unique value generator (Turbine's has been deprecated)
>
This would be needed when adding new portlets to psml files.
>
>- deprecate all pane and portlet references, and replace them with a new
>portlet/portletset reference mechanism, integrating with tools (jlink)
>
>Think about making the portlet id required. It means that old psml files
>will be incompatible until converted.
>
>I agree with Santiago, that we should all agree on a common naming
>convention. I like 'Content' better than 'Clear'...what about
>'PortletElement'?
>
>The default content, an entire portal page is addressed by
>/jetspeed/portal.
>It gets the default layout/template.
>
>What about "/template/PortalElement/peid/42" where
> peid - represents portal element id (see above)
>PEID can represent either a portlet entry or portlet set.
>
Looks better for me than either the original proposal or my amendment :)
>
>Then JetspeedTool would have a 'getPortalElement' method etc.
>Anyway, that's my vote on the naming.
>
>My vote is +1 on this, as long as we make sure it supports other media
>types and constructs as well as IFrames.
>
>Im now going to look into continuing what Paul started on using unique
>ids across the system.
>
>
>>4.1 Decisions
>>
>>Do we want this in Jetspeed?
>>
>
>+1
>
>>
>>Are there improvements to these details that better fit the
>>jetspeed code and intentions?
>>
>
>See above.
>
>>
>>Do we want a single portlet control, or updates to them all?
>>
>
>I like the optional "iframe" attribute on all controls.
>This gives the most flexibility.
>
>>
>>How are we going to identify a portlet within a portal page?
>>
>
>See above.
>
>>What code will support forming this id and finding?
>>
>
>We're still working that out.
>
>>
>>How to change the customizers to support portlet control choice?
>>
>
>Do you mean the 'Iframe' option? Not sure if I understand this question.
>
There were alternatives in Glenn's proposal. If we use a specialized
control, then the customizer should allow for selection of controls
(good in any case). If we use de Iframe option, then it should be
catered for by the current customizer, as both "iframe" and "height"
would be standard attributes.
>
>>
>>Should we surface more iframe control to the user, such as height?
>>
>
>Yes. Perhaps a more detailed design of Iframe customization would help.
>
I think parameters of a portlet are editable by default using the
current customizer. So, if the parameter is there, a basic string edit
capability will be there.
>
>>
>>Should we make the iframe parameters different (bigger
>>height) when the portlet is maximized?
>>
>
>Perhaps a more detailed design of Iframe customization would help.
>
>David
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Jetspeed Proposal: iframe portlet control
Posted by David Sean Taylor <da...@bluesunrise.com>.
Good proposal.
I think that this overall feature should be supported throughout the
project, and not only with iframes, and with different media types.
I like the idea of randomly accessing content, whether it's a portlet, a
portlet with its control, or a collection of portlets. In order for this
to work, we need to have unique ids support. Paul and I have been
discussing this for a while now, and he just committed the start of the
portlet id implementation. Its not complete. We still need to work out:
- a conversion utility to take existing psml files and ensure that a
unique id is added to each and every 'entry' and 'portlets' element.
- modify psml.xsd to mandate an id entry for 'portlets' and 'entry'
change:
<attribute name="id" type="string" minOccurs="1"/>
to:
<attribute name="id" type="string" use="required"/>
- a unique value generator (Turbine's has been deprecated)
- deprecate all pane and portlet references, and replace them with a new
portlet/portletset reference mechanism, integrating with tools (jlink)
Think about making the portlet id required. It means that old psml files
will be incompatible until converted.
I agree with Santiago, that we should all agree on a common naming
convention. I like 'Content' better than 'Clear'...what about
'PortletElement'?
The default content, an entire portal page is addressed by
/jetspeed/portal.
It gets the default layout/template.
What about "/template/PortalElement/peid/42" where
peid - represents portal element id (see above)
PEID can represent either a portlet entry or portlet set.
Then JetspeedTool would have a 'getPortalElement' method etc.
Anyway, that's my vote on the naming.
My vote is +1 on this, as long as we make sure it supports other media
types and constructs as well as IFrames.
Im now going to look into continuing what Paul started on using unique
ids across the system.
> 4.1 Decisions
>
> Do we want this in Jetspeed?
+1
>
> Are there improvements to these details that better fit the
> jetspeed code and intentions?
See above.
>
> Do we want a single portlet control, or updates to them all?
I like the optional "iframe" attribute on all controls.
This gives the most flexibility.
>
> How are we going to identify a portlet within a portal page?
See above.
> What code will support forming this id and finding?
We're still working that out.
>
> How to change the customizers to support portlet control choice?
Do you mean the 'Iframe' option? Not sure if I understand this question.
>
> Should we surface more iframe control to the user, such as height?
Yes. Perhaps a more detailed design of Iframe customization would help.
>
> Should we make the iframe parameters different (bigger
> height) when the portlet is maximized?
Perhaps a more detailed design of Iframe customization would help.
David
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>