Currently the spec says wsrp-url for a resource
must be an absolute address, so I would guess not many consumers would support
this relative address as you specify. I have also noticed not many consumers
support rewriting of resources that are referenced in another resource. For
example an CSS stylesheet that contains another CSS stylesheet
reference.
Currently the producers would have to be involved
in the generating the urls for images within the markup and in the resource
processing of a css stylesheet (unless they contained absolute addresses, this
would be a nightmare in deployment). All they would be doing is replacing the
relative address with an absolute address so it is wsrp specific when required
ie not running in local mode.
Mike
----- Original Message -----
From:
Spector,
Artem
To:
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:]
Sent: Wednesday, March 23, 2005 9:29
PM
To:
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" <>
03/23/05 11:31
AM
To
<>
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:]
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 <>
03/23/05 10:17
AM
To
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
<>*
>
> 03/23/05 09:58 AM
>
>
>
To
>
> 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"
<>*
> >
> > 03/23/05
05:03 AM
> >
> >
> > To
> >
<>
> >
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:]
*
> > Sent:* Tuesday, March 22, 2005 9:58 PM*
>
> To:* *
> >
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 <>*
> >
> >
01/26/05 08:07 AM
> >
> >
> > To
>
>
> > 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.
> > >
> >
>
>
