User guide - xkp/Doc GitHub Wiki

A typical xs application contains two files: description and code. A data file (xml supported at the moment) will describe your application. You implement your functionality on an xs file of the same name. You also may include class files.

Please review the details for each topic lateron this page.

##XML All applications will contain a root node named "application", aside of that everything will be dependent on the type of application. This guide will use the Canvas module in the sample code shown.

An empty application looks like this:

<application width="640" height="480">
</application> 

But where is the fun in that?

<application width="640" height="480" src="tutorial.xs">
    <div x="0" y="0" width="200" height="200">
        <img id="img1" src="kitty.png" placement="center"/>   
    </div>
</application> 

As you can see, the source code for the application will be specified in the property src. Here are some other topics worth mentioning:

The vast majority of applications can be represented as trees. Again, UIs are a prime example of this, but not the only one. Every object declared in the data file has the right to have children and it would be up to the idiom writer to make sense of it.

Every xml attribute used when describing instances (like img1) will directly translate into properties. Properties belonging to the instance type (like src for img1) will assume the specified value. Properties not found in the type will be added verbatim to the object:

<img id="img2" foo="bar"/>

will cause the statement:

string s = img2.foo;

to be valid in code (s == "bar")

You will implement your app's functionality in the xs file referenced by the src tag of your application tag. xs code is always linked (it modifies) to an instance. In the standard case the recepient of the code is the application object.

So, without much noise you can go ahead and start growing your object:

method foo(int bar)
{
   ...
}

will add a method to the application object prototype. But again, that is not much fun. UI applications, for instance, are made of visual controls that the user will interact with (clicking a button) and on such events lies most of the app's functionality. For instance:

on img1.click()
{
    foo(10);
}

For the event sintax look at Events. Here is worth noting a few things:

Events can be implemented "inline", meaning an event for an instance (img1) implemented in the source code of another instance (application). The code for such events run in the scope of the outer instance. That is why the method foo of the application can be called directly.

If you want to avoid this behaviour you can use instances, something like:

instance img1
{
    method bar()
    {
        ...
    }

    on click()
    {
        foo(10); //error
        application.foo(10); //ok
        bar(); //ok
    }
}