logo

Sensible Web Navigation

Domino is good at lots of things yet awful at lots of other things. Ever since Notes databases were made available to the web browser the Domino server has been making a complete hash of some of the most simple tasks. It has been our responsibilty to improve the code generated and, in most cases, over-ride Domino's code with our own.

This article is going to look at an area of Domino code that need serious attention - view/document navigation. When you open a Domino view you hardly ever see all the documents, so a link to the next page is always needed. Similarly a link to the previous page is needed after you've moved to the next page. It's also nice to have next and previous links when you've opened a document - otherwise you have to return to the view and click on the link below/above the current document. Domino can create all these links for us failry easily, but it doesn't do a very good job of it. We need to address this ourselves.

What's the problem?

With lots of things Domino the fact that it's so easy to do most things is often a double-edged sword. The code generated does work but can be lacking in certain aspects. Consider navigating between pages of a view. The easiest way to do this is to create two Action Hotspots on the $$ViewTemplate. The formula is simply:

@DbCommand("Domino"; "ViewPreviousPage")

Or ViewNextPage for a next link. Here's what it would look like in Domino Designer:

As I said earlier, this works. So what's the problem? Well, let's look at the HTML it creates:

<a href="" onclick="return _doClick('80256F4200690CDB.de7341d87e5fbf1380256f4300397381/$Body/0.438', this, null)">&lt;&lt; Previous</a>

What this does is call a JavaScript function called _doClick(). This function simply opens the page again but passes the server the string which tells it what "button" was pressed. Using this information the server can decide what page to return. Why so complicated? I have no idea.

The problem with this code is two-fold. The first problem is that it relies on the browser having JavaScript enabled. The second is that Internet search engines won't be able to follow the link and index any documents further down the view. Search engines only like links which use the href property, which, in this case, points to nothing. They won't follow onclick calls.

Now, most Domino database exist in an intranet environment where search engines don't trawl and we can pretty much rest assured that most browsers (or users) aren't disabled in any way.

On the Internet it's different. There's no common environment that all users share. Not only this but the search engine is king. It's imperative that you make the site as accessible as possible; both to users and search engines. In some instances accessiblilty is even a legal requirement!

A similar problem exists at the document-level. Here we can create similar links to the previous and next document using formula like  @Command([NavigateNext]). The code produced in this case isn't as bad but still problematic. It creates a link to a URL like this:

 /db.nsf/ViewID/DocID?Navigate&To=Next

When you click this link the server returns the browser a HTTP status code of 302. This tells the browser that the document it is looking for is located elsewhere and passes it the correct URL. The URL in this case would be that of the next document.

It's not known for sure, but it's thought that search engines - Google in particular - don't like this kind of link. They can be used to trick the likes of Google in to wrongly indexing or scoring a page's importance, based on its PageRank.

Accessibility aside, there's another less serious problem that is worth mentioning. It's more of a logic thing and is due to Domino not behaving as you might expect it to. When you first open a view or you open the first document in a view you will always see the "previous" link. In the case of the view the link will simply reload the page over and over. With the document it will return the user to the view. The same goes for the last page of the view and the last document. There's also a oddity when moving from one page to the next in a view. The next page always starts with the last document from the first page.

You might think I am just nit-picking now, but this is the level of control that many users/customers demand of a website nowadays. Gone are the days where we could simply impress with any old code. The fact that it was in a browser was impressive enough. Now we need to cater for every sngle whim of the customer.

Solving The Problem:

Don't despair, the problem can be solved. But, as I said, we need to do the coding ourselves.

In both cases the solution involves using a WebQueryOpen Agent for the document and the $$ViewTemplate. If you really don't like this idea, which I don't particularly, then this solution probably isn't your cup of tea. It's taken me a long time to overcome my irrational fear of using Agents in this way. After some self-councilling I've given in and realised that the benefits far out-weigh the performance hit (if there is one at all).

Using an agent we can get a handle on the view and work out how many documents are in it. Using this information we can then use some simple @Functions on the form to create the proper links. We can also tell the user which page they are on and how many there are in total.

At the document-level the agent code locates the current entry in the view and looks for entry before and after it. Based on this information it knows whether to display previous or next links. Not only this but it can provide advanced information about the document, such as their titles.

A Quick Demo:

This article will end with a demo database that you can download. In the mean time let's see what it looks like. Here's the normal view with Domino's non-logical next and previous links. Now look at the improved view where there's no previous link on the first page, nor next link on the last, and there's a counter to tell the user which page they are on. Now look at a document from the view and the links at the bottom. Nice aren't they.

Not only does all this make it easier for our user but the links are now "real" links. Google et al will now be able to get to all the information on the site.

Coding The View:

With the view the agent simply needs to tell us how many documents are in the view in total. We can do the rest using @Functions on the actual "form".

To find the total I first tried the following code:

Set nav = view.CreateViewNav()
Call doc.ReplaceItemValue( "Total", nav.Count)

It worked. But adding thousands of documents to the view soon highlighted the performance problem. The same was true of using a NotesViewEntryCollection. After some testing and re-writing I found the quickest method was to use the EntryCount property of the view.

Call doc.ReplaceItemValue( "Total", view.EntryCount)

However this is an R6 only feature and doesn't cater for categorised views. Sometimes we will still need to use the .Search() method of the database, passing it the same search formula as the view uses. Like so:

Set col = db.Search("Form='article'", Nothing, 0)
Call doc.ReplaceItemValue( "Total", col.Count)

If your view is categorised you can make this formula as complicated as it needs to be. Overall this seems to be the best way to get the count. Some very un-scientific testing led to the following results when using different approaches to find the total.

Approach\Documents (1,000s)510152590
NotesViewNavigator.count2s7s9s--
NotesViewEntryCollection.count--3s--
db.AllDocuments.count--0s0s-
db.Search.count--0s1s3s
view.EntryCount----0s

So, with the "Total" field on our $$ViewTemplate form, which holds the count of all documents, we can go on to create our links.

To work out whether to show links and what they should point to we need a few more fields. First a numeric field called "Start". This field checks for &start=X in the URL. If that parameter is there its value is used. If not it defaults to 1. Then we need another numeric field called "ShowPerPage", which tells us how many documents each page of the view contains. This checks whether there's a URL parameter called Count. If there is its value is used. If not we need to hard-code a number here that is also the actual rows the view displays. In this case I chose 5 and I've set the "Lines to display" property to the same number in the Embedded View's properties, as below:

Now we can work out which links to show and what they should point to. First the "previous" link. This is simply a Computed Text area with the following formula:

@If(Start<=1; @Return("&nbsp;"); "");
newstart:=@If(Start-ShowPerPage<=1; 1; Start-ShowPerPage);
"<a href=\"super/?open&start=" + @Text(newstart) + 
"&count=" + @Text(ShowPerPage) + "\">&laquo; Previous</a>"

The first thing we do here is check whether it's the first page or not. If it is then the text area shows nothing, which is a simple way of hiding the link - as it just doesn't get created.

If there is a page to display it works out where it should start and creates a link to it.

The code for the next page is similar so I won't talk about that. The only other thing to do is display the position of the page. Here's the code:

@If(Total=0 | Total<=ShowPerPage ; 
@Return("Page 1 of 1"); "");

div:=Total/ShowPerPage;
dif:=div-@Integer(div);
pages:=@Integer(div)+@If(dif=0;0;1);
"Page " + @Text(@Integer(Start/ShowPerPage)+1) 
+ " of " + @Text(pages)

The logic is fairly simple. Divide the total by the number on each page. If there's any remainder from the division at all - no matter how small - then we need to round the number up by one. This is the number of pages.

Coding the Form:

Coding the form is a similar process to the view, but all the work is done in the WebQueryOpen Agent. All we need to do is get a handle on the current document and then locate it within the view.

Using the information available via the object we can work out whether it's the first and/or the last document in the view. Knowing this we can then decide if we need to create a link and to what the link should point.

Whereas with the view we couldn't use the NotesViewNavigator object, for performance reasons, the size of the view doesn't seem to affect the time taken to compute information about the current document.

Before we do any of this computing, we need some fields on the form to contain the links. No need to save them so they can be Computed For Display and called whatever you like. I called one PrevDocLink and the other NextDocLink. With the fields there to accept the text for the link we can get on with the coding.

The first thing the code needs to do is create a NotesViewNavigator object and find the current document in it. Without worrying about how we define the objects the code is simply two lines:

Set nav = view.CreateViewNav()
Set ThisEntry = nav.GetEntry(doc)

With this information at hand we can easily find out if it's the first or last entry. To do this we create two other NotesViewEntry objects. One called FirstEntry and one called LastEntry. We can then test whether these are one and the same entry as our current document. Here's the code to work out if it's the first entry:

Set FirstEntry = nav.GetFirstDocument

If ThisEntry.UniversalID = FirstEntry.UniversalID Then 
 Call doc.ReplaceItemValue( "PrevDocLink", "None Found")
Else 
 Call doc.ReplaceItemValue( "PrevDocLink", 
  "<a href=""all/"+nav.GetPrev(ThisEntry).UniversalID+""">Open 
<b><i>"+nav.GetPrev(ThisEntry).Document.GetItemValue("Title")(0) +"</i></b></a>") End If

Make sense? Nothing too compicated about it really. First, test whether the current document and the first document have the same ID. If they do then it's the same thing. If so, set the value of the "link" field to something to say so, or you could just leave it blank. If it isn't then there's a document before the current one and we set the field to a link to it. To make it a little fancy we make the text of the link the actual title of the document.

The code for the next document link is too similar to bother mentioning. And you can see it all in the demo db anyway.

That's pretty much all there is to it with the form. Two fields and some code to fill them in.

Taking it Further:

The code and sample database we're talking about are quite simple. The view is "flat" and there's only one form in it. This doesn't mean it can't handle complicated though. The fact that we are using the .Search() method means we can reproduce any view and any categorisation it might contain.

Summary:

With not a lot of code we've managed to create a much-needed addition to Domino's arsenal. What's not to love about it? The only reason you might not want to use it is the performance hit. Whether this is a factor depends on the size of the database and is down to you to decide.

They say that a user on the internet will wait something like 7 seconds for a response from a server. Personally I suspect it's more like 2 or 3 seconds. If you find that computing the total of your view is taking anything more than a  second it might be worth dropping this approach.

I know that, for me, this is a definite must-have for any Domino site that is going to live on the internet. Not only is it good for the whole user experience but it makes it possible for search engines to trawl effectively. Which is more important? It's hard to say, but ignoring either issue is to be avoided at all costs...

Feedback

    • avatar
    • Jon
    • Mon 8 Nov 2004

    Counting the View

    Jake

    Did you think about using view.EntryCount to get the count? Not sure if it is quicker or not, but may save you using the search. I may have missed something here, or you may have, as it's a new notes 6 property.

    Cheers

    Jon

      • avatar
      • Jake
      • Mon 8 Nov 2004

      Re: Counting the View

      The only reason I didn't think of using this Jon is that I didn't know it existed ;o)

      Thanks for the tip. It looks like a better solution and I'm going to investigate now.

      Show the rest of this thread

      • avatar
      • Jake
      • Mon 8 Nov 2004

      Aricle Updated!

      Ok, thanks again Jon. This seems like the perfect option for "simple" views. I did some testing on a database with 124,000 documents in the view and the compute time was 0s!!

      I've updated the article and demo db to reflect that this is definitely the preferred approach. Search() is only to be used where things like categorisation are to be included and CreateViewNavFromCategory() can't be used as the view is too large.

      Jake

      Show the rest of this thread

  1. prev and next links

    So, of course, I scrambled straight to the demo and I am, as per usual, impressed with your work Jake. Very, very nice.

    But what really caught my attention was that, once inside a document, you have supplied next and previous doc links! From a usability standpoint I feel this is a feature long missing in the Domino blog templates.

    I mosied away from your template a while ago, not because I didn't like it, but because it provided me an excellent starting place to learn. You are constantly supplying fresh ideas that I really appreciate...thank you again.

    Oh, I do not remember the syntax off the top of my head (I'll come back later with it) but now that the docs have the previous/next lnks, there are some head tags that could be populated with this same information. This would be useful for accessibility.

    Thanks, Andrew Barker www.AndrewBarker.com

      • avatar
      • Jake
      • Mon 8 Nov 2004

      Re: prev and next links

      Cheers Andrew. I've just added the view navigation to this sites template and now I'll look at document navigation (articles as well as blogs).

      I know the head tags you mean but can't think of them either...

      Jake

      Show the rest of this thread

  2. what about using hidden @DocNumber column?

    was thinking you could add a hidden column to a view and use @DocNumber. Then use @Subset(@DBColumn("";"";;view; colnum);-1);

    And this would give you the number of docs. Performance might be bad on large views, though, and you might hit the 64k limit.

    Another idea is to keep that @DocNumber column and use script to get db.getlastdocument and pull the @DocNumber column value from the returned doc. Curious how the performance of this would be versus the document collection.count.

    Thanks Jake for your continued writing. I enjoy the site very much-

    Seth Rhode Island, USA

      • avatar
      • Jon
      • Mon 8 Nov 2004

      Re: what about using hidden @DocNumber column?

      You can use @Elements(@DBColumn...) to get the count, if you know the views are never going to get to the 64k limit. I tend to use this method, but then the sites I've used it on, arn't going to reach the 64k limit.

      • avatar
      • Doug
      • Mon 8 Nov 2004

      Re: what about using hidden @DocNumber column?

      Have you tried to grab the @DocNumber column value in LotusScript?

      Last week I was trying to use the @DocNumber column value via a different method in LotusScript and the @DocNumber column was not available to me in LotusScript.

      Thanks.

      Show the rest of this thread

    • avatar
    • Krasna Halopti
    • Mon 8 Nov 2004

    Categorised Views

    Thanks for sharing this technique. In a comment, you mention that for categorised views we can make the formula 'as complicated as it needs to be'. Can you clarify what you mean by this? Strictly, the pagination logic needs to take account of the view entries rather than the documents, and the entry count cannot be easily related to the document count - e.g. a document may appear many times in a categorised view under multiple categories, and there seems no way to count the number of view pages needed (correctly) other using than the NotesViewNavigator.Count. Have I missed something?

      • avatar
      • Jake
      • Mon 8 Nov 2004

      Re: Categorised Views

      A very good point Krasna! It's probably a case of me talking without really doing much thinking ;o)

      What I should do is play with categorised views and, more importantly, test this on views with documents appearing in more than one category.

      Although, in theory, it should be possible using .search(). Imagine a view that shows documents created with the Article form. The first column is categorised by the (multi-value) field called Area. If you want everything in the "test" category then the .search formula is:

      Form="Article" & Area="Test"

      If any of these documents appear in more than one category it shouldn't matter. You can even select them from more than one category, like so:

      Form="Article" & Area="Test":"Another"

      Or you could select documents in a second-level category, like so:

      Form="Article" & Area="Test" & NextLevelFeild="Test2"

      Like I say, I've not actually tested any of this theory, but I can't see why it wouldn;t work.

      Does this help? Did you have a specific problem in mind?

      Show the rest of this thread

      • avatar
      • Sri
      • Wed 12 Jan 2005

      Re: Categorised Views(Sensible Web Navigation)

      Page Of pageno. is not working for Categorized views. Pls help.

    • avatar
    • Matt
    • Thu 11 Nov 2004

    @Functions

    I agree, domino view navigation is poor. I've been doing similar things with @functions for years now. What do you see as the advantage of using script? Just curious if I should change.

    Matt http://www.softscout.com

      • avatar
      • Jake
      • Thu 11 Nov 2004

      Re: @Functions

      I've not tried with @Functions but the biggest drawback would have to be the 64k limit. That's enough to make it unusable.

      Show the rest of this thread

    • avatar
    • David Schmidt
    • Fri 12 Nov 2004

    Data binding

    There is another way, called data binding. Use the TDC and and a view rendered as a csv file. For more info: http://msdn.microsoft.com/library/default.asp?url=/workshop/database/tdc/tabular _data_control_node_entry.asp

      • avatar
      • Brent H
      • Wed 1 Dec 2004

      Re: Data binding

      ActiveX controls are generally a bad thing for internet sites, since they only work with IE.

  3. Show Single Category

    Jake,

    Should this also work with embedded views with show single category selected?

      • avatar
      • Jake
      • Fri 19 Nov 2004

      Re: Show Single Category

      Hi Lisa,

      Yes it works with embedded views and with show single category selected.

      You need to do a bit more programming though and use the CreateViewNavigatorFromCategory (?) method and pass it the same value. I've done this on other apps and it works.

      Jake

      Show the rest of this thread

  4. What about docs with readers fields?

    I've been coding my own Next and Previous links for a while now, though I haven't done anything with Totals as you have here. Just noticed a problem though: I have a site that restricts readers by readers fields but the "Start=" numbers seem to ignore this. My embedded view is set to display 50 docs at a whack. I log in as a user who can only see 2 docs in the view. If I click the Next link, it redisplays the 2nd doc and clicking it again displays the No Docs message. The documents are numbers 38 and 72 in the view, so even though the user can only see this two, the server apparently doesn't take this into account when it runs its numbers. Any way around this? Am I missing something?

      • avatar
      • Jake
      • Fri 3 Dec 2004

      Re: What about docs with readers fields?

      Hi Bob,

      This is something else I hadn't really thought about. Now that I have I can't think of any way round this. Thanks Domino!

      Jake

      Show the rest of this thread

    • avatar
    • christine
    • Wed 8 Dec 2004

    that is great

    this text help me ,it is so great!

  5. Another way of counting, GetAllDocumentsByKey

    Thanks for this great idea Jake. This takes care of one of those very user-unfriendly issues of notes nicely.

    But when I was implementing it, a collegue of mine suggested I try the GetAllDocumentsByKey method instead of the Search method. Since I use a flat categorized view, this is a usable solution for me.

    I just thought I'd share it in this discussion.. maybe you or anyone else could comment on it in terms of server load / calculation time / possible limitations.

  6. Can we access/change the Lines to Display property

    I was wondering if we can modify the embedded views "lines to display" property. In PHP I usually offer the user a simple combo box with various number increments (i.e. 10,20,50,100 200) that allow the user to adjust the page to their liking.

      • avatar
      • Jake Howlett
      • Sun 27 Mar 2005

      Re: Can we access/change the Lines to Display prop

      You should be able to do this using the &count= paramater in the URL.

    1. Re: Can we access/change the Lines to Display property

      There is some property for the entire database, somewhere, that sets lines to display - on my DominoDeveloper.net website it is configureable on a domain by domain basis - probably in Names.nsf or something - I have it set to 10, to save bandwidth.

      I have a question about relative linking: I have a view called html, with html documents in it, served from a Rich Text field called HTMLCODE. If i open a document from a browser:

      localhost/database.nsf/html/index.html

      the images (pulled from a view called web images /webimages/map/$FILE/map.gif

      show up just fine on the web page

      However, I use the Open First Document in a View property to launch the page, and when that happens, all the image links are broken - no images show up. i've tried / and ../ and no /.

      Any suggestions for relative linking here?

      Joel

    • avatar
    • David Schmidt
    • Tue 12 Apr 2005

    XSLT, XPATH & ?readviewentries

    You can mimic this functionality using XSLT, XPATH and ?readviewentries.

    Scenarios for categorized views (flat views are even more simple) Scenario 1 (slower, high cpu + mem usage): You download the whole view in xml using ?readviewentries&expandview&count=….. The data is only fetched once, the whole view is rendered into dynamic html. You can rather easy add smart view navigation and bookmark functionality. Limitation: &count > xxxxxx documents.

    Scenario 2 (faster, more complex): You only download the collapsed view (?readviewentries&collapseview). When the user clicks on a category, the data within that category is loaded into the page (xsl sample: ?ReadViewEntries&amp;Start=<xsl:value-of select="@position" />.1&amp;Count=<xsl:value-of select="@children" />&amp;Collapse=<xsl:value-of select="@position" />.1)

    http://fromdomino.com/__48256E5A001AB060.nsf/plinks/PDWD-5XQCGV http://free.corefusion.net/Free/wausau/home.nsf/$$NavigatorTemplateDefault?OpenF orm http://www.openntf.org/Projects/codebin/codebin.nsf/CodeBySubContributor/3B00647 5E3B5BCDE88256C4800728BCA http://jackratcliff.com/jratcliff/dwt/dwt-demo.nsf

    http://www.w3.org/Style/XSL/ http://www.topxml.com/xsl/default.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/con XSLTDevelopersGuide.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/xmr efxsldecimal-formatelement.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/XPa th_What_Is.asp

      • avatar
      • David Schmidt
      • Tue 12 Apr 2005

      Forgot some good links

      http://www-10.lotus.com/ldd/today.nsf/lookup/DynamicCategorizedViews http://www-10.lotus.com/ldd/sandbox.nsf/cde4d8ccbe98e4868525676e0079ad34/d168b97 e1bb4cccb85256dc8005f58e4?OpenDocument http://www-10.lotus.com/ldd/today.nsf/9148b29c86ffdcd385256658007aaa0f/69922b76f a59de5285256c60004ce0e0?OpenDocument

    • avatar
    • Tony Zhang
    • Fri 29 Apr 2005

    In View to get another views Information

    In a view I want to get another view's information,such as documents count. I used tmp:=@Unique(@DbLookup("":"NoCache";"":"";"cancel";key;2)); total:=@If(@IsError(tmp);0;@Elements(tmp)); to get the count.But it only return 0,and it works good in a form.Which one know why?

      • avatar
      • Jake Howlett
      • Sat 30 Apr 2005

      Re: In View to get another views Information

      DBLookup does not work in a view's column.

      Show the rest of this thread

  7. Search Resultr

    Jake,

    How would you be able to navigate with a view of search results as opposed to a normal view??

    I have made up a web search form, which builds a query and then displays a list of matching documents. The view displays 20 per page, but I am unable to automate buttons at the bottom of the page to do the job of changing the page.

    The standard domino button commands do not work with a search results view.

    I know I need to append "&Count=20" to the URL, adding 20 each time next is pressed and deducting 20 each time previous is pressed.

    Any ideas, there is nothing in the help or the forums about this.

    Many Thanks,

    Matt.

  8. View name from webqueryopen

    Hi All,

    Thanks for the tips over the years Jake. I'm attempting to implement a version of your navigation solution in my own db but am having some trouble.

    I'm opening the views from $$ViewTemplateDefault but can't figure out how I can get a handle on the view in LS in the webqueryopen agent so I can search it. Basically I'm trying to avoid hardcoding the viewname.

    Next thing to try is manipulation of the URL but it seems messy somehow.

    Any pointers very much appreciated. dec.

      • avatar
      • Jake
      • Wed 31 Aug 2005

      Re: View name from webqueryopen

      Declan,

      Add a computed for display field to the $$ViewTemplateDefault form and have it compute to @Subset(@ViewTitle;-1). You can reference the value of this field in your LS code in the WQO agent.

      Jake

    1. Re: View name from webqueryopen

      Hi All,

      I have a $$ViewTemplate with a $ViewBody field displaying a categorised view. When the user clicks on a document, the doc opens and the user can edit, save and close. When he is finished with the doc, he wants to be redirected to the same view but have the category expanded from where he entered the doc. I can get the info I need from the $$ViewTemplate with @UrlQueryString, but having trouble passing and saving this to the doc. I have tried many things, but my mind tells me to try and pass this info from the $$ViewTemplate to the doc by WQO. I just can't figer out how to get a handle on both at once.

      Is there an easier way to get this done?

      Any suggestions would be so appreciated!

      Thanks Janine

      Show the rest of this thread

  9. Show Multiple Values as Separate Entries

    I've hit a bit of a stumbling block while trying to apply the methods in this article to a view which has "Show Multiple Values as Separate Entries" .

    Set nav = view.CreateViewNav() Set ThisEntry = nav.GetEntry(doc)

    The GetEntry does not return anything if the document appears multiple times in the view.

    Am I missing a trick here or is notes working as intended?

      • avatar
      • Ed Lee
      • Thu 26 Jan 2006

      Re: Show Multiple Values as Separate Entries

      Not to worry.

      I ended up using a NotesViewEntryCollection instead which worked OK.

      I haven't done any performance testing on this so I'm unable to say if this is a bad way of doing it.

    1. Alternative for WebQueryOpen Agent

      Excellent article + functions. I do have an alternative though...

      I don't know what the performance hit will be of this alternative, but instead of using the WebQueryOpen agent you can count the totals of the entries in the view with this formula in the Total field:

      @Elements(@DbColumn("";"";"<viewname>";1))

      didn't see any performance drains so far...

      Show the rest of this thread

  10. Genius Jake!.. also, button hotspots & querystring

    First I just want to say how completely brilliant you are. I turn to codestore whenever I have a perplexing domino issue.

    This solves an isse of mine very handily. I have an application where I have a page with an embedded view which relies upon a querystring paramet, "net", to show the proper embedded view.

    At the bottom of my form I have two different rows of buttons, one with just a NEXT button, and one with a PREVIOUS and NEXT

    My PREVIOUS button looks like this: newstart:=@If(Start-ShowPerPage<=1;1;Start-ShowPerPage);

    @URLOpen(wRelPath+"/wSomeDocuments?OpenForm&start="+@Text(newstart)+"&count="+@T ext(ShowPerPage)+"&NET="+TmpNetValue)

    (WRelPath is the relative path, a seperate useful field.).

    I hide the prev/next row of buttons if Start > my ShowPerPage.

    My next button row I hide if Start>ShowPerPage OR Start+ShowPerPage>Total.

    Works phenomenally, and keeps my NET qs parameter in place.

    Thanks again --Steve Lacher

      • avatar
      • Jake Howlett
      • Fri 30 Mar 2007

      Glad you like ;o)

    1. Navigation back from error page without Javascript

      Hey Jake, love your work, been following since 2002 in Melbourne Australia.

      I am making a web app in Domino that has a main page, forms for capture, for mobile devices - without JavaScript (company policy). I am capturing errors with $$ReturnGeneralError, but want to Naviagate BACK to the page with a link on the form rather than using the browser back button.

      Any ideas how I can use either HTML, CSS, or @Formula to navigate back so that I don't lose the data the user just put in?

      I have read your articles on errors, and can't find anything on the web about using @formula or other.

      Paul

      Show the rest of this thread

  11. Navigation must be computed text, not field

    Maybe it's too obvious, but I'd like to leave it here (even if just a mental note to myself):

    The navigational links in a $$ViewTemplate must be calculated in a computed text, not a computed for display field. The field is calculated before the WQO agent has a chance to set the count parameter.

  12. Hello, i was trying to implement this solution but it didn't work.

    I have an application web. A form with an embedded view with a single category and 2 buttons "previous" and "next" to navigate. This works, but when i want to close the document, the application trown a error 404 and modificates mi url.

    Can you help me?

  13. Late to the show here -- I'm worried about how the agent would affect people's use of the back arrow button in their browser -- they get all shirty when you muck with that -- but you've given me an idea for something else.... simply capturing the URL via cgi parameter and subtracting or minusing 100 etc...

Your Comments

Name:
E-mail:
(optional)
Website:
(optional)
Comment:


Navigate other articles in the category "Forms"

« Previous Article Next Article »
Domino Rich Text In The Browser, Advanced   Appending Rich Text Edits

About This Article

Author: Jake Howlett
Category: Forms
Keywords: Navigation;

Attachments

viewlink-v1.1.zip (124 Kbytes)

Options

View Online Demo
Feedback
Print Friendly

Let's Get Social


About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »