Matthias, the bridge does url rewriting as well, and we ignore anything
that has a "javascript:" prefix. Basically, queryStrings only make
sense on URL's that are http and https (or stuff that resolves to
them). I think that orchestra's encodeActionURL needs to be smart
enough to handle this case?
Why? From a logistical standpoint, in the portal things have to be
encoded. Let say we have a tr:goLink that someone assigns to be
"javascript:alert('hi);". There should be no reason this wouldn't work,
yet the go link always encodes it's URL. Should everything that
encode's it's URL have to handle all the perepherial cases or should the
implementation of the encodeActionURL be smart enough to take this into
account? I think the latter.
Therefore, I would say that orchestra should only append the
conversationContext if the protocol is http or https. Or do the
opposite (like the bridge does) and look for protocols to exclude like
ftp: and javascript:.
Scott
Matthias Wessendorf wrote:
Hi,
when using Trinidad's shuttle within an Orchestra application, the
(re)move buttons are not usable.
Why ?
Because Trinidad creates the javascript calls like
String url = "javascript:TrShuttleProxy._moveItems(.......";
and than, we internally encode the url.
Like facesContext.getExternalContext().encodeActionURL(url);
so... with Orchestra, you now get something like:
javascript:TrShuttleProxy._movetems(....);?conversationContext=3
which causes a JS syntax error.
Should we just stop to encode that client side "action" url ?
-M
