Xss - xkp/Doc GitHub Wiki

XSS is a expression language that is at the core of the translation business, you shouldn't confuse it with xs which is a general purpose language. Its syntax is alike to JSP, ASP, etc. You can evaluate expressions, execute xs code and mix the results with templates of your own.

In short, you use XSS to write idioms. You should not confuse idioms as code translators, an idiom translates a xs project into some form of executable application. For instance you could translate your project into an jQuery based web page that can be plugged directly into your site.

Statements

You must understand that xss operation always involve a textual output. XSS is constantly rendering some code, whatever else it finds gets automatically transfered into the current file. The language uses xml-like tags to denote the dynamic parts (those part of the output to be resolved programatically). For instance:

The value is : <xss:e value="23 + 17/3"/> units

will translate into:

The value is : 30.667 units

All recognizable tags will start with xss: here is a list of implemented tags:

• Expression (xss:e)
• Code (xss:code)
• Class (xss:class)
• Instance (xss:instance)
• Marker (xss:marker)
• Brace workaround (xss:open_brace and xss:close_brace)

The Object Model

XSS operates on objects that describe your application, such objects are called XSSObjects (XSO). They contain everything needed in the translation process. Here are some important properties of XSOs:

Duality

XSOs carry the basic information required to render objects. That would be the equivalent to RTTI, accessible with the following properties: properties, methods and events. These properties will be filled with information coming both from application description and its code.

XSOs carry more than that, though. It is often needed that objects contain compiling information. To solve this need the objects were designed to be mutable, meaning that any property that you assign to it will be kept. Suppose you need to mark an object like it has been "processed":

method foo(var obj)
{
    bool has_property = obj has "processed"; //has it been here?
    if (!has_property)
    {
        obj.processed = true; //now "has" would be true
    }
} 

As a general rule, everything not specified on the rtti is not written by the user and should be considered internal information.

Serial

Most objects in a xs application come from the representation of your application, that be from xs or json at the moment. The objects are constructed from data sources automatically and are handed off to the idiom. A little sample:

<application title="Hello World">
    <button id="b1" x="20" y="20"/>
<application/>

This is the basic structure of most xs applications, there will always be an "application" objects that will act as the entry point for xs. Inside of it there will be a list of objects to be interpreted by xss. In this particular case the application object will contain an (rtti) property called "title" and a child object of class "button" and id "b1".

Tree-like

Most applications (all of them?) are represented in a way or another as trees. XSS is aware of that and will read every object and its children. This will be exposed to idioms as a children property (of array type) available on every XSO:

method render_object(var obj)
{
    //recurse
    for(var obj in obj)
    {
        render_child(obj);
    }
}

...

render_object(application);

VM

Eventually most of the statements will require some code to perform the translation deeds. Such code will be written in xs and executed on a virtual machine. Please note the difference between application code (the one written by the user) and code written inside xss statements. User code will never be executed, xss code will never be translated.

We offer a couple helpers:

Compiler

There is an object called "compiler" always in scope. It will be documented later.

Out dsl

This is probably the most used construction in the language. It allows you to access the output from within code. For instance:

for(var prop in obj.properties)
{
    out()
    {
         var <xss:e value="prop.name"/> = <xss:e value="prop.generate_value()"/>;
    }
}

So, as we can see, the out language is simply xss, the difference here is that such xss will run in the context of the code that contains it. In this case the variable prop is visible from the xss code.

Code Generation

It was mentioned before idioms translate projects. User code is translated by their owner objects. Lets explain that... At the application level code can only be written in certain places, like methods or events. The rtti carries a XSO specialization for each of these objects that would provide access to code rendering objects.

for(var mthd in obj.methods)
{
    mthd.code.generate();
}

Here is the rtti spec:

Properties

• name: string
• type: string
• get: code(can be null)
• set: code(can be null)
• value: expression(can be null)

Methods

• name: string
• args: parameters
• code: code

Events

• name: string
• args: parameters
• code: code

Note: The generate method is common to all generable objects (code, parameters, expression). It returns a string.