portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David G. Powers" <jetspeed-...@pssp.com>
Subject WebPageProxyPortlet
Date Thu, 06 Mar 2003 20:34:05 GMT
On Thursday 06 March 2003 11:40 am, Glen Carl wrote:
> This is fine with me. I hope David Powers is seeing this email and can
> check out what was done with the WebBrowserPortlet and the
> IframeProxyPortlet. These portlets are included in the jar I
> referenced. Glen

Yep - I'm seeing it.  

Here's a very brief overview of what I'm prototyping....

WebPageProxyPortlet - Enable navigation of a site within the context of a 
portlet frame.

The connection to the content provider will pass through the Jetspeed 
server.   I haven't given enough thought to ancillary page elements 
(images, applets, flash animations, ActiveX controls, etc...)  initially 
I will just let the browser handle retrieval of these.  Ideally this 
implementation should be a complete proxy elimination the need for a 
route from the browser to the content provider.

The admin / user will set the initial page parameters including:
	URL
	default HTTP headers
		authorization (username/password/method)
		cookies
		user agent
	general config
		field-rename-prefix
		method (GET, POST)
		restrict-nav-to-domain(s) (regex list?)
		restrict-resubmit-list (to prevent multiple payment confirm on reload)


Upon initial request of a proxied item the Portlet will use these default 
parameters to load the page.

A rewriter will filter the content and inject / extract attributes 
necessary to intercept navigation (GET or POST) and maintain state 
(session / authentication) within the content and make it available to 
the Proxy (Action or Servlet).

When a user acts upon a navigation element in the filtered content, the 
proxy (Action or Servlet) will intercept the request and save control 
info via the ProxyPersistenceLayer (interface - first implementation will 
use Session, second will store token in session an attributes in RDBMS).  
Control will then pass to the Portlet - getContent() will use the 
"current" settings to fetch and filter the content and render it.


The rewriter is the trickiest part of this puzzle.  It must at least:
	rewrite href and action attributes to inject proxy URL
	save current target URL in PPL (ProxyPersistenceLayer) stack
	save any other request attributes (method, headers (cookies, etc...)
	rewrite form object names
	rewrite JavaScript function names
	
There is a reason for rewriting the form object names and JavaScript 
function names.  I experienced conflicts with content from a single 
provider.  They used generic javascript includes for form handling.  
Every form used the same function for "onsubmit()" and a set of "global" 
page variables.  I worked around this by renaming the functions and 
variables per requested page, thus I could have multiple Portlets from 
that content provider presented and handled on the same Jetspeed page.


I haven't gone back to edit what I just typed!  There might be some typos, 
glaring omissions, or outright mistakes.  I am very open to any and all 
comments, suggestions, and contributions.

DP


-- 
David G. Powers
PowerSource

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message