Server Objects access

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:

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.
<?xml version="1.0" encoding="utf-8" ?> <context> <handler name="ServerTime" class="WebApplication1.XjHandlers.ExampleHandler" /> </context>
Handler element in this file determines that class WebApplication1.XjHandlers.ExampleHandler will be accessible on client side as a JS object named "ServerTime".

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:
using Cz.Mvvm.Net.Xaja.Attributes; using System; namespace WebApplication1.XjHandlers { public class ExampleHandler { public string Current { get { return DateTime.Now.ToString(); } } [XjCallback("update")] public void Update() { } } }

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






XAJA
XAJA Basics
Advanced
Contact