• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 315
  • Last Modified:

Identifying most popular documents

I'm not sure if this is possible or not, but I'll ask the question anyway......

I'd like to identify the most popular documents in a Lotus Notes database (i.e. those which are viewed the most frequently).
I guess it would be nice to have a counter on each document to identify the number of 'hits'.

Is this at all possible?

0
mrt1
Asked:
mrt1
1 Solution
 
madheeswarCommented:
for that u need to change the form. And add a new field. Update this field with increments of "1" and u can have what u are asking.
0
 
Bozzie4Commented:
That would imply that everybody has editor access, maddy, so not a good solution.

You will have to develop this :
- Notes Client : in QueryOpen event, write a value to an existing document (for instance a profile document) or a separate, new Log document.  Then count the log documents :-)
- Web : use the same technique in a QueryOpen agent (so use Lotusscript libraries) to do the same logging.  

If it's a pure web application, you have more options, for instance by always using a servlet to access the documents (let the servlet count who accesses what), but it's not so clear what to do in the Notes client then.  Advantage here would be you could use it over several databases....

cheers,

Tom
0
 
RanjeetRainCommented:
I implement this wit the help of a public access agent. In every document, I put a window.open that calls an agent passing it necessary parameters. The agent then, with the help of passed parameters, increments the hit count of each document, which is stored separately.

Storing the hit count is much more neat. Besides, if you want to analyze the hit counts (for reporting etc), if you have it at one place, it is fast to access.
0
Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

 
mrt1Author Commented:
Thanks for the responses so far.....all my users have at least edit access, so I'm going for the 'quick and dirty' solution:

Sub Postopen(Source As Notesuidocument)
      On Error Resume Next
      'Update the counter field
      Source.EditMode = True
      Call Source.FieldSetText("Documentation_Counter",Str(Source.FieldGetText("Documentation_Counter") + 1))
      Source.Save
End Sub

The problem I have is that this leaves my document in edit mode, which I don't want. I've tried setting it back using Source.EditMode = False, but this puts me in recursive loop (i.e. changing the edit mode to false seems to fire the PostOpen event again).
Is there an easy way around this?
0
 
BarryTiceCommented:
There's another way, mrt1, though it's a little bit more complicated.

Create another form as a hit counter. For the sake of this discussion, we'll call it Counter. (Actually, you don't need a form for it, as they'll never be directly viewed.)

Create a view to view the documents based on having "Counter" as the "Form" field. For this discussion, call it (Counters). Have the first column display the "Key" field and the second column display the "Count" field.

In your QueryOpen code on your main form, include this code:

'==== BEGIN PASTE ====
Sub Queryopen(Source As Notesuidocument, Mode As Integer, Isnewdoc As Variant, Continue As Variant)
      Dim doc As NotesDocument
      Dim cDoc As NotesDocument
      Dim db As NotesDatabase
      Dim view As NotesView
      
      Set doc = Source.Document
      Set db = doc.ParentDatabase
      Set view = db.GetView("(Counters)")
      Set cDoc = view.GetDocumentByKey(doc.UniversalID)
      If (cDoc Is Nothing) Then
            ' There was no counter document yet. Create one.
            Set cDoc = New NotesDocument(db)
            cDoc.Form = "Counter"
            cDoc.Key = doc.UniversalID
            cDoc.Count = 1
            Call cDoc.Save(True, False)
      Else
            ' There was a counter document. Increment it.
            cDoc.Count = cDoc.Count(0) + 1
            Call cDoc.Save(True, False)
      End If
      Print "This record has been opened" & Str$(cDoc.Count(0)) & " times."
End Sub
'===== END PASTE =====

This will put a count in the information line at the bottom of the client when you open the document.

Or, you can remove the Print line from the script and put a Computed For Display field on the other forms:

@DbLookup("Notes": "NoCache"; ""; "(Counters)"; @Text(@DocUniqueID); 2)

This way, the users who view the documents you're counting never have to edit the documents, which means any other audit-trail-type information you may need for those documents is not muddled with records of people merely looking at the document.

It also means you can have counters for documents that people don't have the authority to edit directly.

-- b.r.t.
0
 
qwaleteeCommented:
This one has been discussed to death in a number of other questions.

The quickl and dirty approach has two major flaws: 1) edit access (you say is no problem), and 2) replication conflicts, which WILL occur if you have multipe  servers, and CAN occur even if not:
    user 1 open doc
    code runs on user 1's clients to update count
    user 1 goes into edit mode
    user 1 begins five minutes worth of editing
    meantime, user two opens doc
    code runs on user 2's client to update count
    user 1 hits save
    user 1's Notes recognizes that the document changes since user 1 opened it (user 2's count update)
    Notes asks user Yes/No to save as conflict doc

The profile doc has three flaws
    again, users need access
    they are cached in the user session, so the count will not be accurate (simultaneous update or multiple updates from multiple users)
    you can't see the update count alongside the document in the view

The non-profile central document has four flaws
    again, users need access -- you can have a separate DB for this
    you can get replication conflicts in the profile document!
    slow
    you can't see the update count alongside the document in the view

I prefer the "generate a log entry per access" aproach.  You need a separate database for the logging that all users have depositor access to, or author access with create document.  The most efficient way to gen the documents is with the NotesLog class.  There are three flaws to this method:
    you can't see the update count alongside the document in the view
    to piece together statistics, you need to count the number of log documents (categorization makes this easier, though)
    you have to maintain an extra database
The actual logging is quick, as NotesLog very efficiently opens a DB, deposits a doc, and closes it.
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Tackle projects and never again get stuck behind a technical roadblock.
Join Now