Re: [wsrp-interop] URL writing and javascript

[Subbu Allamaraju <subbu@bea.com>]

Definitely a tough one.

My take is that, to leave portlet developers some freedom, 
implementations must refrain from using javascript for writing/rewriting 
URLs, or take special care. That is,

a. Consumers don't send templates containing javascript, unless they 
plan to explicitly evaluate it before returning the markup to the browser.

b. Consumers don't rewrite URLs using javascript, at least for URLs 
containing javascript.

Could you elaborate on the motivation for the using javascript functions 
to build URLs?

Regards

Subbu


Richard Jacob wrote:

> 
> 
> 
> 
> Hi all,
> 
> latly we had a question here concerning URL writing in WSRP and java
> script.
> This applies to both Templates and URL-rewriting, same mechanics here.
> I would like to hear your opinions here.
> 
> Assume the Consumer to pass a URL-Template that contains javascript.
>  From the spec point of view this should be perfectly legal.
> 
> renderTemplate="javascript:buildURL('{wsrp-navigationalState}','{wsrp-mode}',.....)" 
> 
> now assume some markup of the portlet like this:
> <a href="javascript:doSomeThing('PortletURL.toString()')> link </a>
> Here (a JSR168 example) the portlet markup uses some function to calculate
> the final URL, like in the JSR168 spec the URL doesn't need to be a real
> URL here (the same applies for our URLs in templates).
> 
> So the result may be that we get nested javascript functions, which doesn't
> work.
> 
> The same applies to rewriting. A portlet might generate some markup
> containing javascript and the consumer also uses javascript after the
> rewriting process to calculate the resulting URL.
> In both cases we have to deal with nested script functions, which are
> forbidden.
> 
> The same problem should occure in JSR168 portlets/container URL handling.
> 
> There may be various solutions for this:
> - forbid the use of javascript in URL generation on either side (we might
> kill a lot of implementations with this?), i.e. do not allow portlets to
> embed the result of a PortletURL.toString-like method in java script, or
> disallow portlet to use javascript in URL generation, or prevent
> containers/consumers to use java script in URL generation???
> - have some nice means to circumvent javascript nesting (javascript helper
> methods?)
> - limit/restrict/explain the usage of javascript in the domain of URL
> generation in the specs?
> 
> I'm not mandating any resolution here, I would just like to hear if you
> feel this is a problem, and if yes how we could resolve it. If no I would
> also hear why (maybe also a resolution :-) ).
> 
> Mit freundlichen Gruessen / best regards,
> 
>         Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> WSRP Standardization Technical Lead
> Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
> Email: mailto:richard.jacob@de.ibm.com
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.
>