Post Reply 
Author Aria templates - Hashspace Bridge
fbasso
AT core team member

Find all posts by this user
Quote this message in a reply
Default  22 May 2014 16:02
1. Requirements

The new template engine hashspace will be out soon. In order to use it with Atlas (the current Aria Templates engine), a “bridge” must be developed.
The purpose of this specification is to define an API to use hashspace and Atlas together.

2. Use Cases

Two main use-cases are expected:
  • Include a hashspace template inside an Atlas template. This allows hashspace to be used in existing applications.
  • Include AT widgets inside a hsp template. This allows to use widgets in hashspace (there is no widgets at the moment in hashspace), and to keep the widgets and skin consistency through the whole application.

3. Technical solution

3.1 Hsp inside Atlas

Only full template can be inserted in an AT template (i.e. 'component', a template with the using keyword, is forbidden). The code allowing the inclusion is available via a new lib :

aria.hsp.HspLib, providing a new widget:

$wlibs : {
    'hsp' : 'aria.hsp.HspLib'
  },

Bridge to hashspace:

{@hsp:Template {
    id: "hspid", // unique id associated to the widget
    type:"div",
    attributes: ..., // html attributes
    hsp: {
       src: getHsp(), // hashspace template
       args: ..., // arguments used by the HSP template
    }
  } /}
  • The getHsp function returns the hashspace template itself, for example require("templates/hsp/tpl.hsp").myTplName. as require being not available inside an Atlas template yet, it must be used via the template script.
  • data is the data model part to be used with the HSP template
  • Other attributes will be used on the container itself (the type attribute) as it is done usually on other widget.

3.2 Atlas inside hsp

Only AT widgets are allowed to be included in HSP. To include Atlas templates, the AT template widget must be used.
The atbridge component will be designed for that purpose. It will be required as any other stuff:

var atlas = require("atlas/atlas.hsp");

Then the AT widget will be included from this component:

<#atlas name="TextField" config="{getConfig()}" lib="foo.bar.MyLib" />
  • lib (optional): AT lib to use, the default is aria.widgets.AriaLib,
  • name: widget name
  • config: AT config bean

3.3 Data binding

Meta data are used inside the data model in order to keep information about what data need to be observed. At the moment, AT and HSP have their own meta data syntax.
In order to fire events in both frameworks, utils.Json.setValue (AT) and json.$set must be overridden to call each other. This will guarantee the full compatibility between the frameworks.

4. Additionnal notes

Regarding the data binding, it is interesting to keep an eye about the (near) future Object.Observe (http://wiki.ecmascript.org/doku.php?id=harmony:observe)
The discrepancies between the Object.Observe specifications and the atlas/hashspace engines are:
  • On Atlas, the data model can be listen recursively. It means that the parent reference is saved in the listen json property to observe (and so on with the parent) in order to notify all listeners in the parents of the data model. This is a functionality to keep in Atlas for full compliance, but not wanted in HSP.
  • By the way, Object.observe does not implement the recursive listener. Should we keep this functionality in Atlas?
  • In the Object.observe specs, the notification is done asynchronously. It means that the listeners are called at the end of the js execution, and not each time a value is changed. If we want, in the future, use the native API, it would be great to implement it this way (based on a queuing system), but it means :
    • It’s not backward compatible on Atlas,
    • It’s not implemented this way on HSP, so the implication must be studied.
5. History

22/05/2014 Spec creation - Fabrice Basso
(This post was last modified: 27 May 2014 13:34 by fbasso.)
b-laporte
AT core team member

Find all posts by this user
Quote this message in a reply
Default  23 May 2014 14:00
My 2 cents on the syntax part:
First, please use 'atlas' to referent the current template engine and not AT that is the name of the full framework.

Then for Hsp inside Atlas:
I would prefer to:
- name the Bridge widget 'Template'
- rename the hsp property 'src' and the data 'arguments' (or 'args'...?)
- and for me the moduleCtrl should be one of the aguments - so no need for a special property
which results in:

{@hsp:Template {
id: "hspid", // unique id associated to the widget
type:"div", // type of the template container element
attributes: ..., // html attributes for the container (div here)
src: getHsp(), // hashspace template
arguments: ... // data model provided to the template
} /}

Btw. the name of the hsp widget lib is a bit complex - why not simply aria.hsp.HspLib ?

For Atlas inside Hsp:
I would simplify the syntax as well and put the aria lib as default - e.g.:

var atlas = require("atlas/atlas.hsp");

// for a widget in aria.widgets.AriaLib:
<#atlas widget="TextField" config="{getConfig()}"/>

// for a widget in another lib:
<#atlas widget="TextField" lib="foo.bar.MyLib" config="{getConfig()}"/>

Finally regarding the Data bindng part"
- having a full polyfill of Object.observe will not add any added value to Hashspace - but will make the runtime much heavier. So I would stay as we are.
- hashspace normally doesn't rely on the fact that changes are notified synchronously - but there could be some minor changes to make if we move asynchronous (notably on the way input value changes are managed) - nothing serious though..
flongo
AT core team member

Find all posts by this user
Quote this message in a reply
26 May 2014 10:38
Hello,

Some clarification about the Bridge widget syntax:
- what does "moduleCtrl" stand for? Put it that way, it seems that it is possible for a hsp template to use an AT module controller.
- if it is the case, we should make sure that (conflicting) properties "data" and "moduleCtrl" behave the same way as in the {@aria:Template /} and {@html:Template /} widgets.
- if neither "data" or "moduleCtrl" are specified, should there be some kind of inheritance (of data model and/or module controller) like in the {@aria:Template /} and {@html:Template /} widgets?
fbasso
AT core team member

Find all posts by this user
Quote this message in a reply
Default  27 May 2014 13:41
Hello,

Thanks for your comments.

I changed the specifications accordingly. Regarding the Hsp inside Atlas and the naming convention, I proposed to embed the hsp things in one json object:

{@hsp:Template {
...
hsp: {
src: getHsp(), // hashspace template
args: ... // Array of arguments used by the template. If needed, the controller must be given to the template in one of these args.
},
...
} /}

Don't hesitate to comment it again if you have any remark.
Post Reply