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.
Copyright © 2000 - 2024 Jake Howlett of Rockall Design ltd. This article was printed from codestore.net