----- Original Message -----
Sent: Thursday, March
24, 2005 9:15 AM
Subject: RE:
[wsrp-interfaces] Applet resources through WSRP
Let’s
look into the flow for a simple example, when a Portlet MyPortlet was deployed with a style sheet
(relative path “css/my.css”)
which contains a URL of a background image “images/bcg.gif”.
- The
Portlet begins with the local path and outputs to the response stream the
string: “css/my.css”.
- The
response wrapper constructs a relative URL which contains the servlet path
(based on the request). The result looks like this: “/portal/applications/MyPortlet/css/my.css”
Now we have two different scenarios: local
portal and WSRP.
Local Portal scenario:
The page content includes the URL as it
was created on step 2: “/portal/applications/MyPortlet/css/my.css”
Note that the image URL inside the css is
still “images/bcg.gif”.
Now for these two resources the browser
issues the following requests:
GET
http://producer/portal/applications/MyPortlet/css/my.css
GET
http://producer/portal/applications/MyPortlet/images/bcg.gif
Everything is OK in this case.
WSRP scenario:
Here we have some additional steps before
the content gets to the browser:
- The
Producer response wrapper converts the URL to absolute (based on the
request) and the result is: “http://producer/portal/applications/MyPortlet/css/my.css”
- The Producer embeds the absolute URL into the resource template (or
the Consumer rewrites the URL): “/portal/resources/my.css?producerUrl=http://producer/portal/applications/MyPortlet/css/my.css&rewriteUrl=true”
When the page is downloaded to the
browser, it issues the following request:
GET
http://consumer/portal/resources/my.css?producerUrl=http://producer/portal/applications/MyPortlet/css/my.css&rewriteUrl=true
Now the Consumer must parse the content of
the resource being downloaded and rewrite the URLs.
Obviously the result of rewriting of
“images/bcg.gif”
should be:
“/portal/resources/bcg.gif?producerUrl=http://producer/portal/applications/MyPortlet/images/bcg.gif&rewriteUrl=false”
But the Consumer cannot compose it because
it doesn’t know the producer-side servlet path (highlighted).
On the second thought the Consumer can
compose the result URL using the producer servlet path taken from the current
request, assuming the inside URLs are relative. This could work! I’ll try
it out…
Artem
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: Wednesday, March 23, 2005
9:29 PM
To:
wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces]
Applet resources through WSRP
If people don't mind, lets walk into this carefully (I am certainly not
an expert on how portals manage urls).
Consider,
for the local portlet case, how the eventual urls gets constructed:
1.
The Portlet begins with a
local/relative URL; example: relative path to a CSS file
2.
The Portal adds to the URL items such
as host and context path to form an absolute url
3.
The loaded resource contains a
local/relative URL; example: a style specifies a background gif
4.
The xxx forms the absolute url.
If xxx
in step #4 is the browser, I would think it would use the baseURL of the page
and therefore construct an absolute url which failed to point at the gif. If
instead it uses the url of the css file, I would suspect the relative reference
to work (including working with WSRP).
if xxx
in step #4 is the Portal, I would think it already has a facility for
preprocessing resources that could be leveraged to generate WSRP type urls
using either Consumer url rewriting or Producer template processing.
Rich
|
"Spector, Artem"
<artem.spector@sap.com>
03/23/05
11:31 AM
|
|
To
|
<wsrp-interfaces@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
|
RE: [Fwd: Re: [wsrp-interfaces] Applet resources through
WSRP]
|
|
Yes, the “entire user experience” was our purpose. From that point
of view the URL string of some resource should be the same whether this URL
“originates” from a Portlet code or from a resource text.
Usually building of Portlet-originated URL takes 3 steps:
1. The Portlet begins with a
local/relative URL
2.
The Producer adds to the URL the
servlet path (including host and context path)
3.
The Consumer wraps the producer-side
URL with its own servlet path (using templates or consumer-side rewriting).
Now let’s consider a resource file containing some local URL. If the
Producer just indicates wsrp-requiresRewrite, then the Consumer has to deal
with this local URL directly. Returning to the 3-step example, the step 2 is
missing.
Honestly I don’t see how the Consumer-side parsing/rewriting of resource
content can be implemented without any Producer assistance.
Artem
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: Wednesday, March 23, 2005 5:28 PM
To: Subbu Allamaraju
Subject: Re: [wsrp-interfaces] Applet resources through WSRP
I agree with the issues you raise. However, if the Producer is doing the url production,
it must do it in a manner that will work for the entire user experience ...
including resources. The idea would be to point out these issues to
implementers and provide some guidance on how they could be addressed. One of
the options could be to use templates for url production in the markup and then
mark resource as needing Consumer url rewriting, but Artem points out that
other options exist if the Producer is willing to manage things properly.
Rich
|
Subbu Allamaraju
<subbu@bea.com>
03/23/05
10:17 AM
|
|
To
|
wsrp-interfaces@lists.oasis-open.org
|
|
cc
|
|
|
Subject
|
Re: [wsrp-interfaces] Applet resources through WSRP
|
|
I agree with that. I'm referring to your comment "the Producer must also
use the templates on the relevant urls within the resource". Such a
requirement, if placed, would assume that the Producer has control over
resource serving, and that it has the templates handy. Both of these may
not be true in most cases.
Subbu
Rich Thompson wrote:
>
> Section 10.2.1.1.3.2 of WSRP v1 lays the burden on the Consumer to parse
> and rewrite urls for resources that set wsrp-requiresRewrite to true.
> Discussion of this requirement within the TC limited the burden to
> string parsing with a replacement of matching substrings. As such, all
> textual types, including CSS, should be parsed. It is likely best if the
> Consumer is agnostic to the resource's mimetype other than a
> determination of what, if any, of the rewritten url needs to be escaped
> in order for it to be valid within the containing document.
>
> Rich
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 03/23/05 09:58 AM
>
>
> To
>
wsrp-interfaces@lists.oasis-open.org
> cc
>
> Subject
> Re:
[wsrp-interfaces] Applet resources through WSRP
>
>
>
>
>
>
>
>
> Rich Thompson wrote:
> >
> > It sounds like you are mixing two issues here:
> >
> > 1. You have validated that applet use has the same
issues as any
> > other url, but not a large set of new
issues. As a special note;
> > resource urls require full name
preservation, whether it be a .gif
> > or a .jar.
> > 2. When Producers use templates for url production
and referenced
> > resources also contain urls, the Producer
must also use the
>
> Can you confirm if the spec requires Producers to rewrite resources it
> is serving over HTTP? AFAIR, this is only a requirement on Consumers
> when the MIME type of the resource is text/xml-like. I think the
> requirement on Producers has implications that we've not discussed
in
> detail.
>
> > templates on the relevant urls within the
resource. This will
> > become easier with the new getResource
operation (important pieces
> > of data are passed on the invocation), but
can be also done by
> > providing a resolver and passing any
required info on the url (or
> > in cookies, though I would prefer to not
explicitly name that
> > option). Note: this includes namespace
resolving as well as url
> > rewriting.
> >
> >
> > Rereading your post, is there also an issue with not all
Consumers
> > rewriting urls within resources (as per the specs
requirements)?
> >
> > I think a couple of additions to the FAQ and Primer from this
> > information might be in order.
> >
> > Rich
> >
> >
> > *"Spector, Artem" <artem.spector@sap.com>*
> >
> > 03/23/05 05:03 AM
> >
> >
> > To
> >
<wsrp-interfaces@lists.oasis-open.org>
> > cc
> >
> > Subject
> >
RE: [wsrp-interfaces] Applet resources through WSRP
> >
> >
> >
> >
> >
> >
> >
> >
> > Yes, we’ve found a solution (we work together with Avi)
and I’d like to
> > share it with you.
> >
> > Actually there are two challenges when composing consumer-side
URLs for
> > producer-side resources:
> > 1. In some cases the resource name
must be preserved in the
> > consumer-side URL (like .jar for applets)
> > 2. Nested resources – if a css
contains URLs, they must be
> > rewritten as well.
> >
> > The solution includes the following aspects:
> > 1. The Consumer modifies the URLs so
that they will end up with
> > the resource names.
> > 2. The Portlets use a standard API
to output resource URLs. In
> > WSRP scenario these calls are intercepted by the Producer,
which does
> > the necessary conversions (for example, URL writing using templates).
> > 3. If the URL references a resource
containing other URLs (like
> > css or js), the producer replaces the resource URL with a URL
pointing
> > to a special producer-side servlet. This servlet acts as a
filter when
> > downloading the resource, and rewrites all the URLs it
contains.
> >
> > For illustration imagine a Portlet called *ExamplePortlet*
which was
> > deployed with image resource */images/r1.gif*. Its
consumer-side URL
> > will look like this:
> >
> _http://consumer.com/portal/consumer/resources/r1.gif?producerUrl=http://producer.com/portlets/ExamplePortlet/images/r1.gif_
>
> >
> >
> > If the Portlet has a style sheet resource */css/r2.css*, its
URL will
> > look like this:
> >
> _http://consumer.com/portal/consumer/resources/r2.css?producerUrl=http://producer.com/producer/resources/r2.css?resourceUrl=http://producer.com/portlets/ExamplePortlet/css/r2.css_
>
> >
> >
> > Now if r2.css contains a reference to r1.gif, then the
producer-side
> > servlet (producer/resources) will invoke the Producer URL
writing logic
> > for this URL. So eventually the image URL returned to the
client within
> > the style sheet will exactly as in the first example.
> >
> > Regards,
> > Artem
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> > Sent:* Tuesday, March 22, 2005 9:58 PM*
> > To:* wsrp-interfaces@lists.oasis-open.org*
> > Subject:* Re: [wsrp-interfaces] Applet resources through WSRP
> >
> >
> > I have been asked this question now by several people ... has
anyone
> > tried referencing an applet in markup from a WSRP portlet? If
so, any
> > guidelines that should be shared with portlet developers?
> >
> > Rich
> >
> > *Subbu Allamaraju <subbu@bea.com>*
> >
> > 01/26/05 08:07 AM
> >
> >
> > To
> >
wsrp-interfaces@lists.oasis-open.org
> > cc
> >
> > Subject
> > Re:
[wsrp-interfaces] Apptel resources through WSRP
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Is the Producer returning the Content-Type header? I've not
tried applet
> > downloading, but if Content-Type does not work, I would try the
> > Content-Disposition header, e.g. with a "inline;
filename=foo.jar"
> > value. In any case, the Consumer has to proxy these headers to
the
> browser.
> >
> > Regards,
> >
> > Subbu
> >
> > Klein, Avi wrote:
> > > Hi,
> > >
> > >
> > >
> > > I wonder if someone has dealt with fetching of
applet as resource.
> > >
> > >
> > >
> > > Whenever rewriting the URL of the applet, the
browser fails to
> fetch it
> > > since it expects the URL to end with *.jar and not
with the
> consumer URL
> > > (result of the rewriting).
> > >
> > >
> > >
> > >
> > >
> > > Thanks,
> > >
> > >
> > >
> > > Avi.
> > >
> >
>
>
