[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