| Key points: |
- This sample uses the same server-side class, BasicCalcServer, and method, BasicCalcServer.Add(), as its prerequisite sample, Complex argument (CA).
- The client-side code, however, is quite different. All of CA's client-side code was hand-coded, whereas most of this sample's client-side code was generated by WebORB.
- WebORB generated client-side encapsulation classes for the server-side classes BasicCalcServer and SumRequest.
- WebORB also generated a client-side class, BasicCalcServerModel, to encapsulate the results returned by BasicCalcServer's public methods.
- BasicCalcServerModel provides the "Model" in a Model-View-Controller architecture.
- What's up with DataTypeInitializer? The Flex compiler has this nasty/useful habit of stripping out any data type which, according to its static analysis, is not instantiated in a given application. On thie one hand this is good, because it keeps code size to a minimum, which is important for Internet applications. On the other hand, it is nasty, because Data Transfer Objects (DTOs) are often instantiated in a manner that's not detectable by static analysis. Hence, the Flex compiler tends to strip out the data types of DTOs (such as, in this example, SumRequest). WebORB's DataTypeInitializer mechanism prevents Flex from stripping out the DTO types by instantiating one instance of each DTO class. It does this in the constructor of the DataTypeInitializer class. In the sample's onLoad() function (in main.mxml), "new DataTypeInitializer()" is called to invoke its initializer, and thereby create an instance of each DTO class. Notice that the result of the "new" operation is not assigned to anything; it is immediately discarded. That doesn't matter. What matters is that by instantiating this one, short-lived instance of the DataTypeInitializer— and hence of each DTO class—the DTO data types will be available for your application's use. The alternative is not fun.
|