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:
- The Portlet begins
with a local/relative URL
- The Producer adds to
the URL the servlet path (including host and context path)
- 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.
> > >
> >
>
>