Quick tip: handling data posted to an XPage
Category xpages
Stephan posted an enlightening article about treating XPages like web agents. He shows how, instead of using an XPage as a visual element, we can block Domino from rendering any markup and manually print to the browser, just like we often do now with agents... except that, since it's still an XPage, we have access to stuff like scoped variables (i.e. we can grab settings directly out memory via the applicationScope instead of having to query the database itself) and the comparative programmatic ease of SSJS. He demonstrates how to set the Content-Type and generate the HTTP response using the facesContext global variable as a starting point.
One other handy use for facesContext is that we finally have a standard way of intercepting request data for GETs and POSTs:
facesContext.getExternalContext().getRequest().getParameter("paramName");
Or, if you're not into the whole chaining thing:
var exCon = facesContext.getExternalContext();
var request = exCon.getRequest(); // This is the actual HTTP servlet request...
var paramValue = request.getParameter("paramName");
So... if the user navigates to "something.nsf/myxpage.xsp?foo=bar", passing "foo" as the paramName returns "bar". Similarly, if an Ajax request posts to "mypage.xsp" and the postData is "foo=bar", same result. In other words, the code of your XPage doesn't care: you can use the same exact method to determine the value of foo, whether it's specified in the URL query string in a GET or submitted via a POST. It just works; you don't need different code for each. Hooray.
P.S. Did you notice something bizarre about that example URL? Something just so... well, anti-Domino? That's right: no ?Open. It's not "pageName.xsp?OpenXPage&someField=someValue"... just "pageName.xsp?someField=someValue" (but, because of the way servlets parse the request, if you forget or get nostalgic, you can include your own ?Open and it'll just ignore it). Finally Domino joins every other web server at the query string syntax party... I guess it just wanted to be "fashionably late".
Stephan posted an enlightening article about treating XPages like web agents. He shows how, instead of using an XPage as a visual element, we can block Domino from rendering any markup and manually print to the browser, just like we often do now with agents... except that, since it's still an XPage, we have access to stuff like scoped variables (i.e. we can grab settings directly out memory via the applicationScope instead of having to query the database itself) and the comparative programmatic ease of SSJS. He demonstrates how to set the Content-Type and generate the HTTP response using the facesContext global variable as a starting point.
One other handy use for facesContext is that we finally have a standard way of intercepting request data for GETs and POSTs:
facesContext.getExternalContext().getRequest().getParameter("paramName");
Or, if you're not into the whole chaining thing:
var exCon = facesContext.getExternalContext();
var request = exCon.getRequest(); // This is the actual HTTP servlet request...
var paramValue = request.getParameter("paramName");
So... if the user navigates to "something.nsf/myxpage.xsp?foo=bar", passing "foo" as the paramName returns "bar". Similarly, if an Ajax request posts to "mypage.xsp" and the postData is "foo=bar", same result. In other words, the code of your XPage doesn't care: you can use the same exact method to determine the value of foo, whether it's specified in the URL query string in a GET or submitted via a POST. It just works; you don't need different code for each. Hooray.
P.S. Did you notice something bizarre about that example URL? Something just so... well, anti-Domino? That's right: no ?Open. It's not "pageName.xsp?OpenXPage&someField=someValue"... just "pageName.xsp?someField=someValue" (but, because of the way servlets parse the request, if you forget or get nostalgic, you can include your own ?Open and it'll just ignore it). Finally Domino joins every other web server at the query string syntax party... I guess it just wanted to be "fashionably late".
Comments