Recently I found myself writing a Java-based Agent in Domino for the first time in a year or more and found myself doing things I'd not thought possible the last time I did.

Until two or three years ago the extent of my "programming" was that I could write Agents which contained simple where, while and if statements. Inside there I'd be calling some .replaceItemValue() and .save() methods. That was about as complicated as it got.

Things only ever got any more complex than that if I stepped away from LotusScript and in to Java Agents. I'd do this only when I needed to. When I was creating PDFs, Zip files or generating images on the fly. Things got a bit more complicated then but all I'd ever be doing is figuring out how to use an existing API. Again, not what you'd call programming.

I never felt like I did any actual programming until I stepped outside Domino and in to C# and ASP.NET development a few years back. Since using C# and reading a few books I'm starting to gain a better understanding and appreciation of the finer aspects of coding.

One of the things I did in the Domino Java Agent was use as enumeration (enum). As an example let's use one to define the various workflow statuses a Notes document can pass through.

Here's the enum definition:

 private enum WorkflowStatus {
    UNKNOWN("Unknown", "The document hasn't yet entered an approval cycle"),
    IN_PROCESS("Awaiting Approval", "There are still approvers in the loop"),
    APPROVED("Approved", "This document has been approved"),
    DECLINED("Declined", "This document was declined");

    private final String value;
    private final String detail;

    private WorkflowStatus(String value, String detail) {
        this.value = value;
        this.detail = detail;
    }

    public static WorkflowStatus findByValue(String value) {
        if(value != null) {
            for(WorkflowStatus status : values()) {
                if(status.value.equals(value)) {
                    return status;
                }
            }
        }

        return WorkflowStatus.UNKNOWN;
    }

    /**
     * @return the value
     */
    public String getFieldValue() {
        return value;
    }

    /**
     * @return the detail
     */
    public String getDetail() {
        return detail;
    }
 }

You can use it in a WQS Agent's Java code like this:

public class JavaAgent extends AgentBase {
 public void NotesMain() {
    Session session = getSession();
    AgentContext agentContext = session.getAgentContext();
    Database database = session.getCurrentDatabase();
    Document document = agentContext.getDocumentContext();

    WorkflowStatus status = WorkflowStatus.findByValue(
            document.getItemValueString("Status")
        );

    switch (status){
        case IN_PROCESS:
            if (document.getItemValueString("AwaitingApprovalBy").equals("")){
                status = WorkflowStatus.APPROVED;
            }
            break;
        case APPROVED:
            status = WorkflowStatus.DECLINED;
            break;
        case UNKNOWN:
            status = WorkflowStatus.IN_PROCESS;
            break;
    }

    document.replaceItemValue("Status", status.getFieldValue());
 }
}

Obviously this isn't real code (it makes no sense to decline an approved document!). It's just to show how the code can utilise the enum.

You could take this further and store a integer value in the backend document, so that you never actually store a string as the status. If you then need to change the definition of a status it becomes a lot easier.

To a degree I've never known whether avoiding hard-coding is really worth it with Domino? More often than not a document is only ever saved and processed using the same WQS Agent. It's only when there's code in multiple places that something like the above enum becomes worth it.

But still, it's all good practise. Using the code above feels a whole lot better than the alternative of scattering string representations of your statuses all over the code.

Another thing I did in the Java Agent was move all strings to the top of the code (things like messages displayed to the user) and defined them as static constants. This way it's easier for me (and future developers) to come and make quick changes without having to sift through all the code.