Xaja makes your GUI ready to be connected with server side. Thanks to simple communication protocol is easy to create server part using any technology, but for current days there is "native" support for ASP.NET. Your project setup will be ready in few minutes:
- Create an ASP.NET application (preferrably empty one for beginning)
- Install XAJA NuGet package
- (alternatively check the downloads page )
Now your application has all required dependencies and also default structure of XAJA project, with sample content. You can note that new generic handler Xaja.ashx was added. It is a "gate" used by whole xaja framework for communication between client and server sides.
Server logic of Xaja application is covered by handlers. You can find sample one in your project as XjHandlers/SampleHandler.cs. Handler is just a plain .NET class, without any special requirements. To make this handler class accessible from client side, you need to register it in context file. In your project, example context file is also created in XjContexts/Xjcontext.xml. Open that file and check out how the ExampleHandler class is registered.
When I said "will be accessible", let's explain what exactly that means. Obviously there is not any magic tunnel between client and server side. All handlers instances are alive only for one request. But Xaja tries to make all that stateless web stuff unnoticeable for the developer. When handler is requested from the client, Xaja creates instance of handler object, serializes it to the JSON and sends to the client. On client side some properties of object could be changed and also method called callback could be invoked. Callback method is just public method of handler class, marked by XjCallback attribute:
When the callback method is invoked on client side, the whole handler object is serialized to JSON and sent to the server. On the server JSON is deserialized to new instance of handler, callback method is called (which usually causes some update of handler state), instance of handler is again serialized to JSON and returned to the client.
State of handler objects passed to client side could be obtained by everyone. Learn how to manage properties visibility here
Sometimes could be useful to have references between particular handlers. It is easily doable by Inject attribute:
In single request multiple handlers could share instance of another one using Inject. According to hierarchy based on Inject usage, Xaja manages which handlers are passed from client, instantiated on server, and also determines proper order of deserialization to always provide alive (ie. populated by received state) instance of handler as subject of injection. Callback could be invoked only on one handler in one request and this particular handler is always "root" of dependency tree.
You might need to access native .NET HttpContext. It is no problem when your handler implements IRequestAware interface:
SetRequest is always called before callback method, so in callback you can rely on informations passed in request.
Server objects access + data binding is just cool...
Let's invite some custom controls stuff into scene
