Re: More digging.

On Thu, 3 Apr 1997, Anselm Baird_Smith wrote:

> Alexandre Rafalovitch writes:
> 
>  > Another problem with LookupState:
>  > 3) It unescapes the path but never escapes it back, when getRemainingPath
>  > is requested. That would create some subtle problems when somebody tries
>  > to write a proxy/redirector resources and uses getRemainingPath to add to
>  > existing url. I think the solution for this (and problem in previous mail)
>  > would be to keep original URI around (already does) and a pointer to
>  > where the last segment has finished and just return a substring of
>  > original URI. That would spare unescaping/escaping, etc.
> 
> Correct. This requires (?) the following (compatible) changes in API:
> 
> getRemainingPath(boolean escaped) {
>    ...
> }
> 
> getRemainingPath() {
>     return getRemainingPath(true);
> }
> 

What about consume flag. Did you get rid of it?

> 
>  > Another thing that show the problem with escaping/unescaping:
>  > 4) Create a resource with a space in its name. (eg directory "test
>  > directory"). Try to access it and familiar "document contains no data"
>  > pops up. Try to modify MirrorDirectory, so it uses getRemainingPath and it
>  > would produce some very interesting results for _some_ of the URLs. Good
>  > example is Add+Extension link on Extensions editor. It becomes unescaped
>  > when it arrives, but later is not escaped before proxy is doing the
>  > request. The only reason MirrorDirectory does not hit this problem is
>  > because it uses original URI string. 
>  > 
> 
> I guess above API changes would overcome that problem ? If I am
> missing something let me know...
> 

I don't think it will. What I am talking about here, is independant from
LookupState (even though similar). This is a problem where editor just
takes a name of the resource and dumps it into form or adds it to URL.
That can lead to all sorts of problems with spaces, double quotes in
names, etc. Of course, nobody should be putting double quotes in the
names, but if they accidently it messes up the browsers and in some cases
are not possible to fix easily. MSIE for example can be particularly
intolerant.... :-{

> No reason, I'll check that vars there are all protected (this solves
> the problem if I didn't miss something ?)

Ok, control example is TextField where value is package protected and not
inheritance protected. (it is missing protected keyword)

> 
>  > Also, setValue and getValue are not
>  > complimentary, they are called by different classes with different
>  > purposes. That might be an entry for the FAQ.
> 
> Could you clarify that point ?
> 
Well, if I am correct, setValue is called by editor to convert value as
entered on html form into internal (File, URL, etc) representation.
getValue is called (by editor?) to set the value of attribute. The
opposite to getValue() which would initialize field to correct value is
either initialize() or constructor (don't remember which). Usually, getFoo
and setFoo are doing complimentary things. Here, they are acting more like
two ends of a pipe. I was just saying that this probably requires some
explanation in manual section for developer. (probably not FAQ, as it is
not a user, but programmer question) 

Keep digging,
  Alex.

Received on Thursday, 3 April 1997 04:15:32 UTC