[I changed the original title of this entry because it wasn't accurate]

This one is a little tricky to explain.  We have been looking at introducing a hierachy for dominoWiki page titles i.e. O/OU/OU1/PROJECT.  Because people are very familiar with slashes I looked at the possibility of including them in a page title.  Understandably I thought a real "/" character might be problematic but we could possibly URLencode and URLdecode the URL so that the title could include "%2F" instead of "/".

I've spent a little time on it and thought it would be worth sharing the results so far.  It's a bit academic because we've decided in favour of disambiguation rather than hierachy.  What follows is quite dominoWiki specific but by the end I think it's a bit more generic.

Creating
Currently it's possible to create dominoWiki pages that contain a slash i.e. Jason/Testing5.  The document gets saved, the normal behaviour then is for that page to open in read mode in the same browser window.
With a title like jason/testing5 this action fails because the url looks like http:/host/wiki.nsf/pages/jason/testing5 and Domino quite understandably treats the whole thing as a path (see next).

Opening
With a url like http:/host/wiki.nsf/pages/jason/testing5 Domino expects to find a view called "Pages\Jason" which contains a matching key for the word "testing5".  In reality the view called Pages contains a document with an index entry of "Jason/Testing5".

If you instead encode the title so that the url looks like http:/host/wiki.nsf/pages/jason%2Ftesting5.  Domino treats "ggswiki.nsf/pages" as the path part of the url and the "jason%2Ftesting5" element as the key.  Domino decodes the %2F in the url and finds the document jason/testing5 in the view "pages".  When you read on you'll see this is strange behaviour because you'd expect Domino to decode the %2F as a slash and treat it like another part of the path.

So at this stage it looks like Domino builds the path from the real slashes.  The pages view column contains values including "jason/test5" and only when interogating the view index does the jason%2Ftesting5 element get decoded from "%2F" into "/" and the document is found.

So it's possible using URLEncoding to open a document using a key containing slashes by URLEncoding.

Editing
Now I want to edit that document.  Normally in dominoWiki a document is opened for editing using a url like: http:/host/wiki.nsf/pages/jason/testing5?edit.  This generates an error because Domino treats "pages/jason/" as path to a view that contains a document "testing5".  And for reasons explained about that doesn't fly.  If I create a view called "Pages\Jason" and it contains a document called "testing5" then the document can be edited.

If I manually change that url to read http:/intranet/ggswiki.nsf/pages/jason%2Ftesting5?edit you might expect the document to be available to edit because of what happens in the ?opendocument case.  But it doesn't.  Domino decodes the %2F into a lash before it extracts the key part.

Summary:
I think Domino is behaving correctly in the ?Edit case it's decoding the path and looking for a host/database/view and then key.  I think the ?opendocument case might be considered a bug if I understand what's happening correctly.

Essentially you'd expect these two urls would either open or edit a document or not but be consistent.  In actual fact they're not consistent.  Open opens and edit does not.

http://host/wiki.nsf/Pages%2FJason%2Ftesting5?opendocument  [Opens the document]
http://host/wiki.nsf/Pages%2FJason%2Ftesting5?editdocument  [Returns an error]


Not sure if all this has made sense so far, it might all seem like Vogon poetry to you.  If so I hope you stopped reading before it provoked your intestines into drastic action

Bye for now