Programatic Access to URL Fragments in Domino
Consider the following URL, which, aptly, points to a page all about URLs.
http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
If you read that page you'll learn a bit about what makes a URL and that the last part following the # is called the fragment identifier (AKA hash or anchor). Although, that's merely trivia.
What I want to know is how we can get server-side access in code to this part of the URL. Say we make a request to Domino with the following URL:
http://server/dir/db.nsf/view/document?open#this_bit
How can we work out it was "this_bit" they were after? Can it be done is @Formula or with a CGI field or a LotusScript property?
Is it even possible at all? Does this fragment part actually get sent to the server or is it merely used by the browser to know which part of the page to move to once it's done loading?
Here's hoping somebody knows the answer and it's not a stupid question.
Skip to the 
You can subscribe to an individual
Was a property of then A tag and the positioning was managed by the browser.
{Link}
The NAME attribute defines a destination for a link. For example, a document containing
<H1><A NAME=foo>My Heading</A></H1>
defines a link destination named "foo" at the indicated heading. One could then use HREF="#foo" in an A element within the same document or HREF="somedoc.html#foo" from within another document.
I don't know that there's a specific function for it, the way you can use query_string to get everything after the initial ?, but if you know there's going to be an anchor in a URL, you could just do StrRightBack(query_string, "#") or @RightBack(query_string; "#").
If only it where that easy Esther. The Query_String doesn't contain the # fragment.
I remember reading about this somewhere else recently. The text to the right of the # doesn't get sent to the web server, which is why you don't see the page refresh in the browser if you are already on the page. If you look in the domlog, you will see it is left off of the requested URL. You can probably use a URL argument in addition to it (&Goto=this_bit#this_bit), then the request will get sent to the server. I guess you can also use an XMLHttpRequest to send it to the server.
I don't believe there is a way to get at that from the server side. It is meant to be information for the browser to know where it should go to on the displayed page. You could probably hack something out in javascript that grabs the value and tosses it into a field.
This is possible. In a round about way. We have a feature that uses the # to specify some content - and it works just fine.
First. Create a .htm page and store it on the server in the HTML folder.
Here's the content of ours. Lets pretend the file name is called frag.htm.
<html>
<head></head>
<body>
<script>
p = document.location.href.indexOf('#');
l = document.location.href.length;
if (p > 0)
{
document.location.href= "/database.nsf/frag?openform&" + document.location.href.substring(p+1,l);
}
</script>
</body>
</html>
Second. Create a redirection rule in the NAB. Ours is...
Description: NAme re-direction
Type of rule: Redirection
Incoming URL pattern: /frag/*
Redirect to this URL: /frag.htm/*
Third. Create a form in your database (replacing the href used in the htm file with the location your form). On this form use the Query_String or Query_String_Decoded to gain access to the # value.
Simple really. Basically we are using the htm file as an intermediary to convert the # value into a standard query string value. Does this prove that the # value DOES get sent to the server? I guess maybe and that Domino ignores it.
I forgot to add. You use the feature like this.....
{Link}
Thanks for confirming this Rich. That's what I thought, but wasn't sure.
Chris' suggestion of adding it as a parameter is the way twisties work - e.g. &Expand=8.1#8.1
you just have to force them to the end of the URL.
@Rich - the script is run client side, so it says nothing about the fragment being sent to the server.
1. Be sure to understand what that is. Is an anchor in a HTML document, normally identified as <a name="anchorName" /> (explained above by Luca)
It is useful to "link" to different parts of an HTML document so the browser client will scroll until that anchor is on top of the screen (if possible).
2. Since I can get the content of any html document using almost any server-side platform (Java, .Net, CGI, COM, etc) I can say that if the html document is well-formed (xhtml ideally) I can parse it and walk that DOM to the node with the attribute name = anchorName and get the content immediately after that node until the end of the parent node of that node (<a name="anchorName" />)
3. You can do that in Domino by creating a Java Agent or a Lotus Script agent and use the HTTPRequest object to get the document and perform the point 2.
does it make sense?
.::AleX::.
One last thing:
under processing on:
{Link}
it indicates that the fragment is all client side.
Usually what's after the hash is just used to move the web page to a specific anchor after it renders -- why would you need it server side?
The only reason I can think of where you would need the server to know what the fragment is would be if your logging page impressions and antw to know if they jumped to a fragment.
While it would not be possible under normal logging conditions to use a cgi variable it is possible to use a javascript function to read the DOM, figure out if the fragment has changed and if so then call some sort of function on the server to record the change. Such a script could also run on a timer to detect if a person jumps from fragment to fragment within the same page.
In my case I'm trying to create an accessible tabbed-layout section, but I'm not sure it's worth going in to the details of that too much, as, as has been said, this is not really something anybody would ever want to do. Was worth a shot though.
C'mon lads, Ajax.
Grab the window.location.href onLoad and covert your #value to a ajaxParser?openAgent&parm=value and use that to select the correct tab by populating your body.innerHTML with the ajax response.
Yes, it is heavily script dependent, but it would work.
But, Jake, if you are in control of how the inbound URLs are formed, why not just add a parm to be processed in the normal query string server side and direct to the correctly selected tab's URL?
I'd be trying to use javascript to provide the tabs action (behaviour), either using ajax or javascript, if the all of the tabs can be loaded initially. (i.e. use js to set an elements style class from visible to hidden styles)
The website (link below) has an article about the three layers of web design. Content, Styles and Behaviour. I think that using # is confusing the content and the behaviour.
In terms of accessibility, loading all the the tabs content at page load will mean that browsers that don't use css or javascript can still read the content.
{Link}
Jake,
Have a look at {Link}
This site uses tabs that hides all but the one you click on.
scripts.js has a list of the javascript files used - one of which is called tabs.js
A late post but fyi it's natively accessible as location.hash
That's native to the browser though Peter.