[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#196] Consumer can not force consumer rewriting tobe used for URLs
I agree that such code tends to exist today, but would note that since the
Consumer may be placing the interaction parameters anywhere in the URL,
there are no safe assumptions about how to break up the template and
reassemble the URL. This situation particularly becomes untenable when the
client side code is computing the value to send for several of the
interaction parameters rather than just inserting additional info into the
URL. In general, it will be quite dangerous to encourage developers to
think they have the same range of choices to accomplish any particular
function in a distributed aggregatable environment as they do in the
point-to-point environment of today's web.
Rich Thompson
"Eilon Reshef" <eilon.reshef@webcollage.com>
01/08/2003 10:20 AM
To: Rich Thompson/Watson/IBM@IBMUS,
<wsrp-wsia@lists.oasis-open.org>
cc:
Subject: RE: [wsrp-wsia] [I#196] Consumer can not force
consumer rewriting to be used for URLs
Rich,
I agree with you in theory, but I believe that practice may be different
at times.
I apologize if my previous example was slightly over-simplified, but I
believe your statement " 2. Producer never breaks up a template when
storing it for client side JavaScript use. This would be a dangerous thing
to do anyway and therefore merits a mention in the primer as well." is the
one that may break in practice.
A common example is JavaScript that generates URLs. Without WSRP, a code
snippet may be something along the lines of the fictitious one:
function doAction(actionId, doUndo)
{
var actionString = actions[actionId]
actionUrl = "/doAction.jsp?action=" + actionString + "&do=";
if (doUndo)
actionUrl += "yes";
else
actionUrl += "no";
document.location.href = actionUrl;
}
A more common example is with images, e.g., functions like
function turnOnOff (image, imageName, onOff)
{
image.src = "/images/" + imageName + (onOff ? "_on" : "_off");
}
The above code appears whenever things like dynamic buttons or roll-overs
need to be implemented.
The way I see this happening with WSRP is by the Portlet server-side code
breaking the template(!) and the client-side code re-assembling the URL.
E.g., (one implementation)
function turnOnOff (image, imageName, onOff)
{
image.src = GLOBAL_imageTemplatePrefix + "/images/" + imageName + (onOff
? "_on" : "_off") + GLOBAL_imageTemplateSuffix;
}
The server-side code would be reponsible for putting the GLOBAL_
JavaScript variables so that the above code would work correctly.
To generalize this, your assumption holds if you assume that all the URLs
in the system are generated server-side (in which case they can be
correctly relayed to the Consumer, who can correctly rewrite them). In all
other cases, the templates need to go back to the client in a
Producer/Portlet specific manner.
To summarize:
- I think that some of the situations illustrated above can be changed
(code-wise) so that everything is done server-side. However, I would hate
to be the "coding police" and I doubt whether we have the mandate.
- I think that those situations are common enough so that we can't (and
don't want to) explicitly discourage them in a best-practices document
(again, I hate to be the "coding police").
- I think that those situations are not common enough for us to devise a
complete architecture around them. As long as the Producer can do it with
reasonable effort (which I think is the case), I think we are on safe
grounds.
To summarize the specific point at hand: I think that the Producer should
be allowed to assume that the templates send to it are valid URLs/URIs for
otherwise the above scenarios won't work. I would suggest adding a
statement along the lines of "The templates, once replaced with valid
values, SHOULD be a valid URLs, as specified in RFCxxxx." And I completely
favor approaches such as the one that started this thread, in which a
Consumer knowingly gives up those scenarios and provides a template of a
different format.
Regards,
Eilon
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, January 08, 2003 8:30 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#196] Consumer can not force consumer rewriting
to be used for URLs
Lets think through the scenario to see where it could break:
1) The Consumer defines its template in such a manner that Consumer URL
writing is used
[fragment => ...&wsrp-navigationalState={wsrp-navigationalState}]
2) Producer stores this template in its markup for embedded javascript to
use
[fragment =>
...&wsrp-navigationalState={wsrp-navigationalState}]
3) Consumer finds the embedded template and rewrites it
[fragment => ...&ns={wsrp-navigationalState} or
/ns_{wsrp-navigationalState}/]
4) JavaScript runs and replaces the Producer supplied values
[fragment => ...&ns=fooBar or /ns_fooBar/]
5) URL is activated for Consumer processing
To me this looks like it works provided:
1. Consumer finds/replaces "&wsrp-navigationalState=" and does not touch
{wsrp-navigationalState} => worth mentioning in the primer to avoid
Consumer bugs in this area.
2. Producer never breaks up a template when storing it for client side
JavaScript use. This would be a dangerous thing to do anyway and therefore
merits a mention in the primer as well.
I am starting to wonder if we are gathering enough of these types of
things that we should consider a "Best Practices" document as well. We
certainly should be using a separate portion of the primer from the
tutorial until we are ready for splitting in this manner ....
Rich Thompson
Carsten Leue <CLEUE@de.ibm.com>
01/08/2003 03:58 AM
To: Eilon Reshef <eilon.reshef@webcollage.com>
cc: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#196] Consumer can not force
consumer rewriting to be used for URLs
Hi Eilon.
Can you detail on this. I think I do not understand why the approach to
provide ANY tempalte (including the one that results in consumer
rewriting)
should not work for the javascript code. That would worry me.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
Eilon Reshef
<eilon.reshef@web
collage.com> To
wsrp-wsia@lists.oasis-open.org
01/07/2003 07:59 cc
PM
Subject
RE: [wsrp-wsia] [I#196] Consumer
can not force consumer rewriting to
be used for URLs
This could be a great way to test WSRP initially. To the best of my
understanding, though, such a technique would not necessarily be
applicable
to real-life situations. For example, if a Producer has JavaScript that
executes document.location.href = url; and the Producer takes care to
create a proper JavaScript (which takes into account the provided
templates), then providing the Producer with a dummy template is not
guaranteed to work. (I.e., we rightfully don't demand Producers to support
this hack ;-)
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, January 02, 2003 8:26 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] [I#196] Consumer can not force consumer
rewriting to be used for URLs
It is quite easy to supply a default template that results in
Producer URL
writing outputting the format for Consumer URL rewriting.
Rich Thompson
Gil Tayar <Gil.Tayar@webcollage.com>
12/18/2002 04:04 AM
To: wsrp-wsia@lists.oasis-open.org
cc:
Subject: [wsrp-wsia] [I#196] Consumer can not force
consumer rewriting to be used for URLs
Issue: 196
Status: Active
Topic: user_info
Class: Minor_Technical
Raised by: Andre Kramer
Title: Consumer can not force consumer rewriting to be used for URLs
Date Added: 18-Dec-2002
Document Section: v0.85/9.2
Description:
In the 1.0 timeframe, it would be good, for testing and bug work
arounds,
to allow the consumer to not supply templates to a producer which
indicates "doesURLTemplateProcessing", so that consumer URL
rewriting
is
forced to be used. [Spec says consumer MUST supply templates but all
URL
templates are nilable or minOccurs="0".]
Resolution:
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC