If I know you as well as I should I think you ought to like this one!

Remember way back in 2003 I wrote about Processing multiple documents from a view?

It's a useful way in which to perform a certain action on a chosen set of documents in a view. It was all fairly simple stuff. In the case of the demo I put online back then all the backend code did was change one field value, based on which button was pressed.

The methodology used is still useful — although, in practice, you might want to perform more involved actions on each selected document. Now though, I've now come up with a much better way of doing it. That is, it's better if all you want to do is edit each document's fields directly, with no other logic involved, which is often the case.

What I found myself needing (and subsequently coding) this week was something like an InViewEdit solution, but for the web. Without the AJAX or JavaScript that is. Just good old HTML and a funky backend agent.

Although the actual requirement that made me arrive at the solution was quite simple, here's a more complex example of it in use. Click the screen shot below to go to the actual view and have a play.

Do us a favour while you're there — add some content and mess about with it. I'm keen to find any bugs there might be.

Bugs aside there is one rather major limitation. The processing agent refers to the Request_Content field, which has a 64kb limit. In the demo form this equates to about 300 rows. Although this should be plenty it's a same the limit exists. IBM have "removed" the limit in 7.0.1 but basing a workaround on that would be nigh on impossible with the approach I've taken.

As you'd expect, once it's ready for the prime time I'll put all the code and write-up in an article with the download. For the curious you can probably work out what's happening by examining the HTML and looking at the LotusScript of the Agent that the form gets POSTed to.

This solution came about due to the specific needs of a client's application. They like their privacy so I won't say what the need was. Let's say, for the sake of example, that they arrange meetings and need to know who attended. Each person invited is recorded as a child document of the meeting document. After each meeting they go to a view (restricted to category of parent document ID) called "Needs attendance recording". The view shows attendee documents where the Attendee field is blank. The view shows the attendees name along with a Yes/No radio button to quickly mark the attendance of all the people who were invited in one go. You can see this concept in the unmarked view.