I see how the consumer would rewrite the url in the
portlet markup
<link rel="stylesheet" type="text/css"
href="wsrp-rewrite?wsrp-url=http://producer/portal/applications/MyPortlet/css/my.css&requiresRewrite=True"\>
and then the stylesheet itself
contains
backimage {
background-image:url(wsrp-rewrite?wsrp-url=http://producer/portal/applications/MyPortlet/images/bcg.gif&requiresRewrite=false);
}
but not if the stylesheet contains
backimage {
background-image:url(wsrp-rewrite?wsrp-url=images/bcg.gif&requiresRewrite=false);
}
This is the bit I don't get "The consumer has has enough information to convert relative URL
images/bcg.gif"
This part I do not see as being part of the WSRP
spec and consumers required to process relative to absolute urls.
If the producer has a wrapper for resource css
stylesheet that takes the
backimage{
background-image:url(images/bcg.gif);
}
and converts it to
backimage {
background-image:url(wsrp-rewrite?wsrp-url=http://producer/portal/applications/MyPortlet/images/bcg.gif&requiresRewrite=false);
}
before it is sent back to the consumer then
everything works fine.
Mike
----- Original Message -----
From:
Spector,
Artem
To:
Sent: Thursday, March 24, 2005 11:11
AM
Subject: RE: [wsrp-interfaces] Applet
resources through WSRP
Please note that in
my example the wsrp-url is absolute (step 4), though the Portlet code operates
with relative URLs.
As for the relative
urls contained in other resources, they can be rewritten by the Consumers
without any assistance from the Producers.
I’ve tried to show
that when the Consumer processes the request
GET http://consumer/portal/resources/my.css?wsrpUrl=http://producer/portal/applications/MyPortlet/css/my.css&requiresRewrite=true
and parses the input
stream, it has enough information to convert relative URL images/bcg.gif into something
like
“/portal/resources/bcg.gif?wsrpUrl=http://producer/portal/applications/MyPortlet/images/bcg.gif&requiresRewrite=false”
Doesn’t the spec
require the Consumers to respect the wsrp-requiresRewrite
flag?
Artem
From: Mike
Caffyn [mailto:]
Sent: Thursday, March 24, 2005 5:08
PM
To:
Subject: Re: [wsrp-interfaces] Applet
resources through WSRP
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.
> > >
> >
>
>
