Appending Rich Text Edits
A recent request from a client of mine was to mimic a feature of a bug-tracking system they use. The feature was a part of a non-Domino website, but they wanted it adding to their Domino system. It wasn't something I'd been asked to do before then and isn't something I've seen described elsewhere. Hence, I will describe the problem and solution now.
The Situation:
The system in question is called FogBugz. It's used to report and track bugs and issues. In this screenshot and the image below you can see the typical content of a bug report.
The content of this page is made up of all the comments that people post as it goes through the workflow. Users can edit documents and add their comments, but they can not edit what has already been said by others.
To reproduce this in Domino we need to append each user's comment to the end of one big Rich Text field. How do we do this without allowing the user to edit the content already in there? That was the problem I was faced with.
The Solution:
There may be an easier alternative, but this is what I came up with and it works. Instead of the usual solitary Rich Text field I've used three of them. The forms look something like this:
Why three fields? Well, one - Body - is for storing the content and displaying it when the document is in read mode. The others - Temp and Display - are used for user input and displaying current content, respectively, in edit mode. Maybe it could be done with two, but I've not looked in to this really. If it can then do let me know.
What do these fields do? Well, as I said, Body is used to store all the content in the document. The other two aren't strored on the document and are removed using LotusScript in the WebQuerySave agent. Temp is only ever an empty field for user input. Display is used to show current content when in edit mode. There's a reason this can't simply be the Body field, but I can't remember it now. The content of the Display field is added by the WebQueryOpen agent.
What code's needed? Well, noting too complicated really. We just need to get a hold of the existing Body field and add whatever is in the Temp field to it. The complicated bit is where we try and add some style to the lines inserted to separate each edit.
In a diversion from my usual style of writing articles I am not to going to describe the code in detail. Instead I am going to let you guys work it out by downloading the sample database and figuring it out for yourselves. This saves me a lot of time and makes it easier for me to get more stuff to you in a timely fashion.
You might have noticed an option in the form that lets you chose whether to store the contents as HTML or not. What effect does this have? One obvious difference is that you get the HTML editor. The main difference though is that the backend document is stored in HTML. If you don't select this option the whole thing is stored in Notes rich text format. This is beneficial if you want to make sure searching works as you'd expect or if you want to read/edit the content in the Notes Client.
What use is this?
What you might use this for is down to you. The example of a bug tracking solution is a good one, but you could employ it in most workflow situations. It could even be used in a forum-style situation or even for a blog where all readers' comments are appended.
The Negatives
There are drawbacks to this solution. For a start a user can't edit their comments after posting them. And what if we wanted to delete their comments ? It's not as easy as it would be if each comment posted were stored in a separate document.
The Positive& lt; /strong>
There is a bonus though. Searching becomes easier. Only one hit will be returned by a full-text search and there's no need to find which document it was that contained what you're looking for.
Summary
This is a simple yet effective cludge of a solution. You might not even have realised this could be useful before now. Hopefully you will find a use for it somewhere.
Me too
Hey I had the same problem. Mine was an IT help desk where both IT staff and users could have a chat like the above.
The big problem is the one of searching, and that's when you come up against the limitation of the Notes database format. You can't return one search result based on the contents of multiple documents.
So in the end the searchable help database contains only resolved issues. That way when an issue is close I can slurp all the responses into one RTitem and have the issue doc searchable.
Current issues are searchable but only for the contents of the help request... oh well.
Reply
Individual Edit
Hi Jake,
After reading your article, i thought of a solution that might work for your database.
What you need to do is to create a seperate RichText fields for each entry made. (e.g. Body_1, Body_2, Body_3, etc....).
All these fields will be combined into your Body field. This will be used for Searching and Displaying. Each entry in the Body field will be within a unique DIV, that is given an ID
(e.g. <div id="Body_1">......</div> <div id="Body_2">......</div> . . <div id="Body_X">......</div>)
When you put the document in Edit Mode you can loop through the content (i.e. 1 to X) and look for the ID (i.e. Body_1 to Body_X).
You can then replace the text found with your usual buttons (i.e. Edit, Delete, etc...). Because each Button knows it's own index, you can then open the document and edit the corresponding field.
This can be made more intelligent, by recording the User who made the entry in a corresponding User Index field (i.e. Body_1 = User_1, etc...). Then only the author of the entry can edit, delete, etc...
When a users deletes an entry, your WQS agent can remove the Index field, renumber the subsequent fields (e.g. 2 => 1, 3 => 2, etc...), and then rebuild the Body field.
I know that this is a little bit rough, but i think it can be done and would not require any Javascript. Should be easy enough to implement in your code!
Later
Patrick
(P.S. All comments are welcome!)
Reply
two fields
I think you should be able to set [body] element to 'read only' in edit mode so you don't have to have the [display] field....
Reply
Re: two fields
"read only"? You mean computed?
Reply
Hide the rest of this thread
Re: two fields
Readonly is a input/text field property you can use instead of using computed fields. I have used it a couple of times for fields I don't want users typing in. Here's a link to an article that can explain it a little better:
http://www.cs.tut.fi/~jkorpela/forms/readonly.html
I believe the only drawback is it can only be used in input/text fields.
Reply
Whatever works
I used a similar technique with a pop-up window using a second form, where the WQS would store the contents in a computed RTF on the original doc, if memory serves me right.
Whatever works for the problem at hand! :-)
Reply
Domino features vs. all others
This article was very timely for me, because I've been a long-time Domino developer (and perhaps rightly-biased), and also because I've begun to dabble a bit with Drupal lately and the limitations of similar CMSs.
There's a whole world of CMSs out there. I mentioned Drupal, while also Joomla and Typo3 also have merits.
Compared against wonderful and mostly efficient discussion forums such as Notes.net, I find all these other boards' discussions 'flat', and hard to read and navigate. I think discussion forums are extremely valuable knowledge bases, the value of which extends well beyond the initial plea for help. Notes.net is an example of such a GUI done right, while all the others are an inefficient pain and generate inefficient results.
Thanks to this article and thread, now I 'get' the merits of having all comments within a single page. *Searchability*, ah! Thanks guys! (I blame the codestore readable gui for misleading me though, because it is so well implemented.)
Now I wonder, since notes.net seems almost idealic aside from this newly gleamed omission, I wonder, how can this 'feature' be added?
Couldn't an agent scrape up response and response-to-response docs and compile such a page? Maybe search could even be redirected to focus on such (new) pages?
Anyway, that's just me thinking out loud. Nice article and discussion! Food for thought.
Reply
Another Approach
I did something similar but used a popup dialog to show a comments journal (very similar to your screen there). The dialog is made up of an embedded view which shows comments in date order (saved as different documents), and the "Add Comment" dialog has a mini rich-text editor with basic text formatting options. It works well, and allows checkbox delete as well as editing existing comments.
Reply
Attachments and links....?
Hello Jake first: Big congratualtions on your wedding!!! You are about to find out if all the jokes and sayings are true....
Well on to business; Does your solution accept attachments and/or links?
Reason for asking is that we have a similar add-to-thread feature in our it-support database but we miss the opportunity to add files, screen dumps, links e.t.c. As it is today we keep these in a seperate field.
Best regards, Hans Borgen
Reply
Re: Attachments and links....?
Hi Hans,
To add files to this solution would involve using the file upload control. There's no way of adding them directly to the body field like the way it works in the Notes client.
Jake
Reply
This is great
This is great.
Reply