OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] Namespacing revisited


> 
> IMO, wsrp-rewrite?.../wsrp-rewrite should be restricted for the purposes 
> of constructing URLs.

I second this. The section on URLs would be simpler if the namespacing 
issue is dealt with separately.

A reserved token (e.g., wsrp-namespace) for the prefix would be lot 
simpler for both portlet developers and consumers.

Subbu



> Using a prefix it's much more readable, #PREFIX#doNothing(). And note 
> that the consumer does not need to generate a unique prefix upfront, it 
> could handle a special token and resolve the prefix at consumer 
> rewriting time.
> 
> We could also define a wsrp-namespace$ token to be used as prefix when 
> doing consumer rewriting. I wouldn't use the 'wsrp-rewrite$' (as 
> proposed by Rich) as this is an overload that may create confusion.
> 
> But if I'm doing producer rewriting, I need the namespacePrefix. That's 
> way I say it should be a required field.
> 
> Alejandro
> 
> On Thursday, June 12, 2003, at 10:37 AM, Rich Thompson wrote:
> 
> 
>     It was brought up on today's call that the primary target for
>     namespacing is not particularly well served by the current design.
>     lets consider a simple JavaScript function:
> 
>       function doNothing() {}
> 
>     To namespace this today, one has to rewrite it as:
> 
>       function
>     wsrp-rewrite?wsrp-urlType=namespace&wsrp-token=doNothing/wrsp-rewrite()
>     {}
> 
>     Points made about this rewrite:
>       1. Rather unwieldy and certainly not obvious that the function
>     name was originally "doNothing"
>       2. It is not valid to run as is and this makes testing much more
>     difficult
> 
>     The question was raised as to whether we could easily specify a
>     constant prefix token that this author could use that would leave
>     the code both readable and testable while not requiring the Consumer
>     to do two parsing passes. Here is a proposal:
> 
>     1. Define "wsrp-rewrite$" as a token indicating that a token
>     requiring namespacing follows
>     2. Require that a space (%20) follow the token to cleanly delimit
>     the end of the token needing namespacing.
> 
>     The author would rewrite our example function as:
> 
>       function wsrp-rewrite$doNothing () {}
> 
>     This almost works. The problem is that JavaScript names can not
>     contain a "-" character. It would work if our delimiting token was
>     changed to wsrp_rewrite so that this example becomes:
> 
>       function wsrp_rewrite$doNothing () {}
> 
>     and the Consumer URL rewriting expression changes to:
> 
>      
>     wsrp_rewrite?wsrp-urlType=value&name1=value1&name2=value2.../wsrp_rewrite
> 
> 
>     Rich Thompson 
> 
> 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]