There is less classic Domino work around then there used to be ( Pure Java, mobile and Xpages taking up most of my time), but still plenty of maintenance work for those who can provide what the client wants, any way, this is something I just updated on an existing clients classic app, and it struck me that it MUST be known by just about every one, but either no one has blogged it, or my Google foo is weak at the moment, so I decided to post it in case I might be of some use.

Problem: you have a classic search form, and you want to analyse or work with the results (making totals or stuff like that), but need to somehow get hold of the values in order to do so, I can remember this being a complete PITA years ago, but with a fresh set of eyes its dead easy.

Solution:

1) Make your searching view a HTML one (via the view properties).

2) Make a column that returns a hidden field for each row for the value(s) that you want to access.

"<td>" + "<input name="PostCodeSearchValue"  value="" + PostCode + "" type="hidden" />" + "</td>"

3) Now when you search, you can go a fetch all these values with client side java script.

var coll = document.getElementsByName("PostCodeSearchValue");
var arr = [];
for (var i = 0; i < coll.length; i++) { 
 arr[i] = document.getElementsByName("PostCodeSearchValue").item(i).value;
 }

and do what ever you want with them.

Now that lacked a bit description wise, so here is a demo and working download for you to take to bits

Demo: Here , Just Click “Search” to get a bunch of data to work with and then “Find Unique Postcodes” to run a bit of Javascript over the result to find and display the unique Post Codes in the returned data

DownLoad: You can get the file Here

ahhh, History…

update: Matt White has pointed out that this produces invald HMTL (working but invalid), and suggests using a JS framework and doing the same sort of “find” but using a CSS Class name… a fine point

Old Comments
————
##### Mark(07/06/2012 16:24:22 GDT)
Does that mean you are making a separate search call? rather than a local bit of JS dealing with the data you already have? if you were wanting to total a value for the items the existing search had returned how would you be doing that in the context of a $$search form?
##### Mark Barton(07/06/2012 15:59:29 GDT)
Yes – rather than HTML in the search view columns just construct JSON data, or am I missing something?
##### Mark Barton(07/06/2012 15:28:30 GDT)
Couldn’t you just return JSON?
##### Mark(07/06/2012 15:31:32 GDT)
as part of the search form data?

REST services are really nice, really fast and easy to create, but sometimes we forget in our haste to get them out the door that a little bit of structure will help both our selves and any third party developer than might user them, eg, if when a call is made to your service

[]

is returned, what does that mean? was it sucessfull but there is no data, or was there an error in your call, a bit of context would go a long way, the easiest way round this is a little wrapper class, nothing fancy, just enough to throw the front end devs a bone, my basic one looks like this

package com.ldc.classes;
public class RESTReturn {  
    public static final Integer SUCCESS = 0;
    public static final Integer FAILED_GENERAL = 1;
    public static final Integer FAILED_INVALID_PARAMETER_VALUES = 2;
    public static final Integer FAILED_MISSING_PARAMETER = 3;
    public static final Integer FAILED_AUTHENTICATION_FAILURE = 4;
    public static final Integer FAILED_AUTHORISATION_FAILURE = 5;
    public static final Integer FAILED_AUTHENTICATION_EXPIRED = 6;
    public RESTReturn() {
    }
    public RESTReturn(int returnStatusParm) {
        returnStatus = returnStatusParm;
        returnStatusDesc = statusToString(returnStatusParm);
    }
    private int returnStatus;
    private String returnStatusDesc;
    private Object payload;
    public int getReturnStatus() {
        return returnStatus;
    }
    public void setReturnStatus(int returnStatus) {
        this.returnStatus = returnStatus;
    }
    public String getReturnStatusDesc() {
        return returnStatusDesc;
    }
    public void setReturnStatusDesc(String returnStatusDesc) {
        this.returnStatusDesc = returnStatusDesc;
    }
    public Object getPayload() {
        return payload;
    }
    public void setPayload(Object payload) {
        this.payload = payload;
    }
    public static String statusToString(Integer wsReturn) {
        if (SUCCESS.equals(wsReturn)) {
            return "It Worked";
        } else if (FAILED_GENERAL.equals(wsReturn)) {
            return "Error: This call caused an error";
        } else if (FAILED_INVALID_PARAMETER_VALUES.equals(wsReturn)) {
            return "Error: Something you gave me was rubbished";
        } else if (FAILED_MISSING_PARAMETER.equals(wsReturn)) {
            return "Error: You left somthing out";
        } else if (FAILED_AUTHENTICATION_FAILURE.equals(wsReturn)) {
            return "Error: Err user name or password was wrong";
        } else if (FAILED_AUTHORISATION_FAILURE.equals(wsReturn)) {
            return "Error: You you can log on, but you dont have rights to do that";
        } else if (FAILED_AUTHENTICATION_EXPIRED.equals(wsReturn)) {
            return "Error: Your logon has expired, sorry";
        } else {
            return null;
        }
    }
}

and I would use it a bit like this

package com.ldc.classes;
import java.util.List;
public class Getaddress {
    public RESTReturn getAddressInJSON() {
        int callStatus = RESTReturn.SUCCESS;
        List<Address> someAddresses = null;
        try {
            someAddresses = doSomthingToGetALoadOfAddress();
        } catch (Exception e) {
            callStatus = RESTReturn.FAILED_GENERAL;
        }
        RESTReturn restReturn = new RESTReturn();
        restReturn.setReturnStatus(callStatus);
        restReturn.setReturnStatusDesc(RESTReturn.statusToString(callStatus));
        restReturn.setPayload(someAddresses);
        return restReturn;
    }
}

so instead of

[]

I would get

{"returnStatus":1,"returnStatusDesc":"Error: This call caused an error", "payload" : "[]"}

which at least tells you that something is not right with the world

Obviously you can get as creative as you want, and a lot depends on how good your internal functions are at displaying their unhappiness, but every little helps and you will make better friends with your client side devs for a bit of consideration like this

Thanks to Ben Poole for pointing out to me that I’m behind the times as normal and this is standard practice, doh!!

Old Comments
————
##### Mark Barton(01/06/2012 14:32:21 GDT)
I wonder though if you should throw a HTTP Status != 200 e.g. 404 along with the custom exception error message.

Its then trivial to catch an error using something like JQuery.
##### Mark(01/06/2012 14:37:24 GDT)
Good point, in this case I have found that this kind of structure is most beloved of the mobile apps lot, who prefer to handle such errors separately due to the someone unreliable nature of mobile networks, but it would be a good idea to use http status items (goes off to look)