[CONF] Apache CXF 2.0 Documentation: JavaScript Client Code (page edited)

[confluence]

Page Edited : CXF20DOC : _javascript_ Client Code _javascript_ Client Code has been edited by Benson Margulies (Dec 24, 2007). (View changes) Content: Structure of the Code There are three types of _javascript_ code: Utilities Schema Service Utilities The utilities code is a fixed set of _javascript_ that provides some browser compatibility and XML management. This code is delivered in the distribution in the file etc/cxf-utils.js. If you are using the ?js URL handler, it is delivered at the beginning of the response (unless you add ?nojsutils to the URL). If you are generating _javascript_ using the tools, it is up to you to copy this file and to use it. Schema Code The Schema code generates one object for each 'bean' used in your service. This code is organized by XML Schema. The code for each schema starts with a comment like: // // Definitions for schema: http://apache.org/hello_world_soap_http/types // file:/home/benson/cxf/trunk/distribution/src/main/release/samples/js_browser_client/wsdl/hello_world.wsdl#types1 // The generator generates a _javascript_ constructor for each global complex type and element in the schema. Generally, you will find that the service methods are defined in terms of types, not elements. However, depending on whether you use Document or RPC, and depending on exactly how you configure your parts and types, you may find that a particular method is defined in terms of an 'element'-based _javascript_ type instead of a 'type'-based class. A typical _javascript_ class for a type looks like: function apache_org_hello_world_soap_http_types_sayHiResponse () { this._responseType = ''; } function apache_org_hello_world_soap_http_types_sayHiResponse_getResponseType() { return this._responseType;} apache_org_hello_world_soap_http_types_sayHiResponse.prototype.getResponseType = apache_org_hello_world_soap_http_types_sayHiResponse_getResponseType; function apache_org_hello_world_soap_http_types_sayHiResponse_setResponseType(value) {this._responseType = value;} apache_org_hello_world_soap_http_types_sayHiResponse.prototype.setResponseType = apache_org_hello_world_soap_http_types_sayHiResponse_setResponseType; This is very simple type, derived from the return part of a Document/Literal service. It has one piece of data in it, called 'responseType'. Note that the code style here is to define getters and setters over 'private' properties. The code does not go to elaborate lengths to make the properties private; it just puts an _ on the front of the names. Service Code The code for a service starts with a comment, followed by a constructor for the per-service object: // _javascript_ for {http://apache.org/hello_world_soap_http}Greeter function apache_org_hello_world_soap_http_Greeter () { this.jsutils = new CxfApacheOrgUtil(); this.synchronous = false; this.url = "" class="code-keyword">null; this.client = null; this.response = null; this._onsuccess = null; this._onerror = null; } There are two important properties defined here: url and synchronous. URL You are responsible for setting the url property with the URL of the web service. The generated _javascript_ does not include any concept of services and ports. You simply put the appropriate URL into the property. Note: CXF's _javascript_ clients don't support cross-scripting. If you want to cross-script, you have some choices: Stick with Mozilla/Firefox and sign the code. Modify the utils to use some of the common workarounds that permit cross-scripting in some browsers in some circumstances. Synchronous and Asynchronous processing The CXF _javascript_ code generator is designed to facilitate typical, AJAX, asynchronous processing. As described below, the per-operation functions take callbacks as parameters, and call them back when the server responds. If you want to use synchronous communications, you can set the 'synchronous' property to 'true'. That does not change the API, but rather changes the behavior. With this setting, the operation functions do not return until after the server has responded and the callbacks have been called back. Per-Operation Functions The code generator generates a function for each operation. Unless the operation is one way, the function will take two callback parameters plus the parameters for the operation itself. The first two parameters are the success callback and the error callback. OneWay operations have no callbacks, they are "fire and forget." The success callback is called back with one parameter: the _javascript_ object corresponding to the response. What is that object? Well, that depends on the schema of the operation. If you are using Document/Literal/Wrapped, it will be a _javascript_ object corresponding to the wrapper object for the output part. If you are using Document/Literal/Bare, it will correspond to the output part. If the output part has a simple type, such as String, the response callback will be called with a simple _javascript_ object. The error callback will be called only when the server responds with an HTTP error status. It will be called with two parameters: the HTTP status number and the HTTP status text. When/if the client _javascript_ generator is improved to have more comprehensive support for faults, the protocol will change to pass fault information as a third parameter to the error callback. Understanding the Parameters of Operation Functions If you have a choice in the matter, and you are using Document/Literal, the present author recommends bare as opposed to wrapped methods. This pushes all the type management from the front end (JAX-WS or Simple) to the data binding (JAXB or Aegis). The data bindings offer much clearer configuration control over namespaces and such than the frontends. In general, you will probably feel the need to read the _javascript_ code to understand the binding in complex cases. One possible future enhancement of the generator is to generate more comments, or perhaps even an HTML explanation, to assist in this process. Examples of Calling Services Here are some snippets of calls to services. You should expect to inspect the generated _javascript_ to learn the names of classes and functions. A Document/Literal/Bare Service The present author finds that, at least for JAX-WS, BARE has a lot to recommend it, as it avoids surprising interactions between JAX-WS and JAXB. function errorCallback(httpStatus, httpStatusText) { globalErrorStatus = httpStatus; // integer HTTP status globalStatusText = httpStatusText; // Textual HTTP status } function successCallback(responseObject) { // the parameter is an object of the type declared for the // method. globalResponseObject = responseObject; } function compliantTest(url) { var intf; // class for the service. intf = new org_apache_cxf_javascript_fortest_SimpleDocLitBare(); intf.url = "" var bareParam = new my_param_class_object(); bareParam.setWhatever(someValue); // ... intf.compliant(successCallback, errorCallback, bareParam); } xs:any Example: Using a Described Type The following function calls a Document/Literal/Bare method. The bare parameter element is declared as: <element name="acceptAny1"> <complexType> <sequence> <element name='before' type='string' /> <any minOccurs='1' maxOccurs='1' namespace='##other' /> <element name='after' type='string' /> </sequence> </complexType> </element> The target namespace for this schema is uri:cxf.apache.org:jstest:types:any. This particular xs:any allows any single XML element from some namespace other than the target namespace of the schema containing 'acceptAny1'. (Note that JAXB only supports xs:any for ##other, and interprets it to forbid unqualified elements. If need more flexibility, consider another data binding.) The WSDL contains a reference to another schema, with target namespace uri:cxf.apache.org:jstest:types:any:alts. That namespace includes an element named alternative1. In the function below, the _javascript_ creates an object for the service, and then an object for the acceptAny1 element. It fills in the slots for the simple before and after elements. For the xs:any element, it creates an object of type org_apache_cxf_any_holder. This type, defined in cxf-utils.js, holds an object for an element defined in the WSDL's schemas. To construct one, you supply the URI and local names of the element, and then the value. For built-in types, use the XML Schema URI (http://www.w3.org/2001/XMLSchema) and the name of the type (e.g. 'string'). function testAny1ToServerChalk(url) { var service = new cxf_apache_org_jstest_any_AcceptAny(); service.url = "" var param = new cxf_apache_org_jstest_types_any_acceptAny1(); param.setBefore("before chalk"); var anyOb = new cxf_apache_org_jstest_types_any_alts_alternative1(); anyOb.setChalk("bismuth"); var holder = new org_apache_cxf_any_holder("uri:cxf.apache.org:jstest:types:any:alts", "alternative1", anyOb); param.setAny(holder); param.setAfter("after chalk"); service.acceptAny1(param); } What if your xs:any calls for more than one item? You supply an array of holders, since each holder could be some different element. xs:any Using Raw XML CXF also allows you to provide the XML yourself. The XML you provide must be valid. If the elements are qualified, you must define the namespace definitions with appropriate xmlns attributes. Here is an example. Note in this example that the element is qualified; it lives in the uri:iam namespace. JAXB does not permit unqualified elements, at least in the current version of the reference implementation that CXF uses. If your xs:any accepts multiple elements, you supply a single holder with a XML fragment containing multiple elements. Note the use of org_apache_cxf_raw_any_holder to pass the XML to CXF. Also note that CXF does not support raw XML passed from the server to the client. In a return value, you will always find a org_apache_cxf_any_holder. However, the raw holder has a 'raw' property with value 'true', and the non-raw holder has a 'raw' property with value 'false'. CXF may be enhanced to support passing non-described elements to _javascript_ at a later time. function testAny1ToServerRaw(url) { var service = new cxf_apache_org_jstest_any_AcceptAny(); service.url = "" var param = new cxf_apache_org_jstest_types_any_acceptAny1(); param.setBefore("before chalk"); var holder = new org_apache_cxf_raw_any_holder("<walrus xmlns='uri:iam'>tusks</walrus>"); param.setAny(holder); param.setAfter("after chalk"); service.acceptAny1(param); }

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences