Well, the second path doesn't return results, so perhaps the issue is in the JCR Query/QueryManager? It appears that its encoding the "_", which is apparently a valid value to query against. So I really don't understand why it would encode that character. Either way, I'll just be careful with encoding. :)
Thanks for the response. Respectfully, John On Fri, Sep 11, 2009 at 10:00 AM, Felix Meschberger <[email protected]>wrote: > Hi, > > John Crawford schrieb: > > Saw an issue with this the other day and wanted to pass it along to see > if > > it was a bug or intended functionality. > > So, to encode elements in a path that begin with a number I used the > encode > > functionality in ISO9075. At one point, I accidentally "over fixed" the > > path by calling the encode method too many times on the path. It > actually > > gave me an invalid path (it encoded it's encode). I found this pretty > easy > > to reproduce as it happens in the CRX Explorer as well. > > > > Ex: > > path = /content/path/to/my/2009/08/node > > path = encode( path ); // returns > > /content/path/to/my/_x0032_009/_x0030_8/node/ > > path = encode( path ); // > > returns /content/path/to/my/_x005f_x0032_009/_x005f_x0030_8/node > > In what respect do you think this path is invalid ? > > If you encode an input, it has to encode the input. There is no way the > method can tell, whether the second encoding is due to a programming > error or is requested by intent. So the result of encoding agains sounds > reasonable. > > Regards > Felix > > > > > Again, if this is intended functionality, no worries. Just wanted to > > verify. > > > > Respectfully, > > John > > >
