RE: [wsrp-wsia] [I#196] Consumer can not force consumer rewriting tobe used for URLs

[Eilon Reshef <eilon.reshef@webcollage.com>]

Title: Message

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>