Display responses on every page
An alternate title for this article could have been "CodeStore Revealed Part III". This is indeed another article in response to common requests that I let you all know how I design certain parts of the site. One such request regards how I get the list of responses to appear at the bottom of each article. You might recognise the similar format to that employed at the Notes.net Forum:
CodeStore uses exactly the same method to produce this list. Where does it come from? How come not everybody knows about it? The answer to both of these is that it is only in the Discussion Template in version 4.6. Why they decided to leave it out in version 5 is anybody's guess ... The problem is that not everybody has access to the version 4 templates, particularly if they are working in a completely R5 environment. Nor does everybody realise that this functionality is readily available in the template. Fortunately you can download the Forum's Template from this Sandbox entry.
When you've got in to either of the templates there are only two design elements that you need to copy in to your site:
- The (Threads) view
- The Thread Subform
All we need to do now is make a few changes to each, add some fields to your forms and it should all just fall together. I could leave you to work it out for yourself but what kind of guy would that make me? and more importantly - how useless would this article be?! Despite which it is worth explaining how this works in detail as it can be quite daunting to get to grips with.
Let's take a look at the design of the view:
The first change we need to make is to the view's Selection Formula. Change this to select both your main form and any of its responses that you want to appear in the "Thread" list. Notice in the above shot that the view shows documents without the hierarchy. This is so that we have a "flat" view and can do a lookup on the first column. This column contains the Document UNID of the main document at the top level of the response hierarchy. The other columns are used to sort the document and to build the HTML for the structure of the links in the Thread list. In order To build this view we need to add certain fields to our forms.
In the "main" form we need to add the following hidden fields:
- MainID
- Computed
- @Text(@DocumentUniqueID)
- ThreadID
- Computed When Composed
- @Unique
- ThreadSort
- Computed When Composed
- temp := @Text(@Created ;"T0S1"); @Text(@Year(@Created); "G") + @Text(@Created; "D2S0") + @Right(temp; 2) + @Left(temp; 8) + " " + @Text(@DocumentUniqueID)
On the repsonse forms we need to add the following fields most of which inherit their values from the main document:
- MainID
- Computed When Composed
- MainID
- ThreadID
- Computed When Composed
- ThreadID
- ThreadSort
- Computed When Composed
- FIELD ThreadSort := ThreadSort; temp := @Text(@Created ;"T0S1"); ThreadSort + " " + @Text(@Year(@Created); "G") + @Text(@Created; "D2S0") + @Right(temp; 2) + @Left(temp; 8) + " " + @Text(@DocumentUniqueID)
- ThreadIndent
- Computed When Composed
- ThreadIndent + ". . "
All you should need to do now is add the "Thread" subform somewhere at the bottom of your forms in the place you want your "Thread" lsit. Et voila.
Can it really be that easy? Usually not. Unless you make direct copies of all the design elements from the template (including the fields listed above) you are likely to have made a mistake (I usually do). This technique is extremely tempremental. One small change or error in a formula can mean the rest of it all falls to pieces....
And finally...
Let's take a look at the formula that makes all of this work. This is in the ThreadMapDisplay field in the Thread subform:
temp := @DbLookup("":"NoCache"; ""; "(Threads)";MainID; 2);
temp1 := @If(@IsError(temp);"";temp);
ThreadMap :=@If(temp1 = "" ;"[<font size=-1><i>  Thread information not available.</i></font><!-- ignore// -->]";temp1);
myhref := @If(Form = "Response";". . ";"") + "[<a href=\"" + @LowerCase(@Text(@DocumentUniqueID)) + "?OpenDocument\">";
myend := "<!--"+@LowerCase(@Text(@DocumentUniqueID))+"-->";
@ReplaceSubstring(
@ReplaceSubstring(
@Implode(ThreadMap; @NewLine);
myhref; "[<img src=\"/icons/vwicn118\">" + @Right(myhref;"[") + "<b>"
);
myend; " </b><img src=\"/icons/vwicn118\">"
)
This is the bit you need to be careful with when/if you tailor the layout like I have done a little. The basic principle is fairly straightforward - we do a lookup on the Threads view using the MainID that is unique to each thread. The column of values we return is the HTML we need to build the list. The formula then finds the current document within this list and places icons around that entry so as we know where we are.
Note: If you are adding this to an existing database you will need to populate all the fields in the each of the documents before the view can build the thread. You should be able to do this with a simple @Command([ToolsRefreshSelectedDocs]) agent.
Thanks
I actually did ask you about it a while ago. Thanks for explaning it in detail.
Reply
This is very helpful
Thanks! This certianly is helpful!
Reply
Be aware of field size limit
I ran into an error when the lookup (for ThreadMapDisplay) exceeded the size limit for plain text fields, which is 15K for storage although I don't think it actually broke until it reached 32K. My database is being used more as a documentation database than a discussion... I'd hope it would be unlikely to hit the limit in the latter. Anyway, I got around it by using a rich text field (64K limit per paragraph) to hold the HTML. I was able to dynamically put the HTML into it by using a WebQueryOpen agent. Instead of an @DbLookup (64K limit), I use view.GetDocumentByKey, followed by GetNextDocument for each matching document, writing each as its own paragraph.
Reply
Re: Be aware of field size limit
At what point did you run into problems? How many responses will cause a database to break?
Running into this limit is potentially tricky. If it happens on a viewtemplatedefault form or on your opening page, it can make it impossible to open the database in he Notes client or design client. You can get round it by writing an agent in another database to delete documents in the db that you can't open - but its not good.
Reply
Re: Be aware of field size limit
You can also change the ThreadMap field calculated for display by a computed text.
I had the same pb of size as you, I solved it by doing that.
Regards from France
Fabrice P
Reply
Discussion Template in Sandbox is R5
I checked the forum template on Notes.net and it's R5 and not R4.6. One resulting problem is neither of the template files in the .ZIP has a Thread subform with a ThreadMapDisplay field.
Can someone tell me where I can download the R4 template?
Reply
Re: Discussion Template in Sandbox is R5
They moved the ThreadMapDisplay field to the actual form...
Reply
It's very useful
that's it
Reply
Thanks !!
This helped me a great deal.
Reply
Here's another way to do this...
So, I was searching and of course Jake has already done what I am trying to do :) But, I wanted to do it a bit differently, so I came up with an alternative way to do this. You can read about it on my blog:
http://www.lotusgeek.com/SapphireOak/LotusGeekBlog.nsf/d6plinks/ROLR-64W58E
Hope this helps - enjoy!
--Rock
Reply
ultimate code
your js is ultimate ,its solve my problem
Thanks for it
Reply