WebProxy Portlet Best Practices

 

Note:  Work in progress.  Information taken from http://jasig.275507.n4.nabble.com/data-ajax-returns-does-not-display-data-within-webproxy-portlet-td4355777.html.

The following best practices will make it much easier to successfully use the Web Proxy portlet.  You should also follow the other portlet best practices documented on Portlet Development.

URL Rewriting in Javascript

The Web Proxy Portlet will re-write URLs in content to direct the destination of the request back to the Web Proxy Portlet so it can proxy the operation.  URLs in Javascript are not processed so the content and javascript must be constructed in a manner that takes advantage of the portlet's URL rewriting behavior.  Using psedo-code to illustrate the technique:

Doesn't work, URL is hidden from the portlet content processing in a javascript block:

<script>
function doSomething() {
    $.ajax('/some/url?param1' + p1, function() { AJAX HANDLER });
}
</script>

Should work, URL is a hidden, named, anchor:

<!-- In JSP page -->
<!-- Store the portlet namespace string in the JSP page variable "n" -->
<c:set var="n"><portlet:namespace/></c:set>

<script>
function doSomething() {
    var u = $("#{n}decentLinkName").href();
    $.ajax(u, {'param1', p1,}, function() { AJAX HANDLER });
}
</script>
<a id="{n}decentLinkName" class="ajax_link hidden" href="/some/url" />

Dependent Javascript Libraries and Ajax

If you are using Ajax to update the content of the web proxy portlet, you can use the WPP's ability to do pre/post static html to pull in any specific versions of jQuery or other javascript libraries so they are loaded only once to avoid memory leaks.  You can load in the specific library version in pre-processing and create a no-conflict reference, then in the post-procesing use a closure to make the reference ($ or whatever) available.  See JavaScript Best Practices for additional information.

Inline Javascript

There are problems with “inline” JavaScript, like below:

<script language="JavaScript">
  function helloWorld(){
    alert ("Hello from WebProxyPortlet!");
  }
</script> 

When this code is proxied, the WebProxyPortlet “engine”  adds an empty “src” attribute, so the first line looks like this: <script language=”JavaScript” src=””>.  As the result, Firefox and Chrome just ignore those JS functions. IE and Opera were just fine.  If you move the function into a separate JS file, things started to work as they are supposed to.