OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interop] URL writing and javascript






Perhaps build new URL was not the precise term here.
I could imagine portal frameworks on the consumer side to, for example,
open a pop-up window depending on the mode/windows state in the render URL.
For example a portal might want to open a seperate window for the edit or
help mode.

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


                                                                           
             Subbu Allamaraju                                              
             <subbu@bea.com>                                               
                                                                        To 
             06/17/2004 07:14          wsrp-interop@lists.oasis-open.org   
             PM                                                         cc 
                                                                           
                                                                   Subject 
                                       Re: [wsrp-interop] URL writing and  
                                       javascript                          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




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
.
>


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
.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]