For all configuration files QxTransformer uses json format. [DRAFT] Tag mapping Tag mapping configuration uses to connect xml tags and templates which are used to process them and render javascript code. Configuration file looks like: { ... //top widgets "qx:application": { //qx:application has no parent "body" : { "*": "body/qx/application.mako" }, //do not need to add qx:application to any parent, // it's a top level widget, so template is null //also this structure can be ommited "add" : { "*": "" }, "data": { "attr": { //default value for "extend" attribute //will be used if user doen't provide extend among other //tag's attributes explicitly "extend":"qx.application.Standalone" } } } ... } Key name for every data structure is a name of xml tag. On the previous example you can see a configuration for qx:application tag. Possible options: tag-name -> extends body -> * qxt:* qx:* tag-name add -> * qxt:* qx:* tagname attributes -> * qxt:* qx:* attribute-name data -> attr -> key:value props -> key:value As you can see the main key for all configuration structure is name of tag, like qx:application or qx:button, etc. It means that this configuration block is provided for this tag, and when the system find such tag in processed xml it will use this configuration. There are 5 top-level configuration parameters: 1) extends - you can extend configuration one from another. Chain can contain more that one element. So you can define all similar parts in base tags and override or add new ones in children. The rules how the system processes this is following: - if a child has the same key as a parent has, it will be overridden(hashes will be merged) - if a child has a new key/value pair, it will be added in resulted config It's very similar to merging hash structures. 2) body - templates mapping to process a body of a widget. Processing of an any xml node consists of 3 parts: - body processing (creating instance, attaching event function, etc.) - adding to parent - processing of attributes Body templates defines the first stage from this list. A xml tag can be processed in different way depend on its parent. Sometimes it needs to processes the same xml structures in different ways and generate different javascript code depend on parent of current node. Body (and other templates) definitions allow doing it easily. Body template definition : { ... "qx:tag" : { ... "body" : { "qx:application": "path/to/template_application", "qx:hbox": "path/to/template_hbox", "qx:*": "path/to/template_qx", "qxt:*": "path/to/template_qxt", "*": "path/to/template_all" } ... } } The configuration defined above means: 1) qx:tag will be processed with template "path/to/template_application" if its parent is qx:application 2) qx:tag will be processed with template "path/to/template_hbox" if its parent is qx:hbox 3) qx:tag will be processed with template "path/to/template_qx" if its parent has namespace qx but not qx:application and qx:hbox 4) qx:tag will be processed with template "path/to/template_qxt" if its parent has namespace qxt 5) qx:tag will be processed with template "path/to/template_all" if its parent does not comply with rules above 3) add - templates mapping to generate 'add' structure in order to add child to parent. It's very similar to body definition: { ... "qx:tag" : { ... "add" : { "qx:application": "path/to/template_application", "qx:hbox": "path/to/template_hbox", "qx:*": "path/to/template_qx", "qxt:*": "path/to/template_qxt", "*": "path/to/template_all" } ... } } and works in the same way. [Further improvements]: It would be good to have possibility don't define all parent tags explicitly but defined only their base config. 4) attributes - templates mapping to process attributes of a xml node. All xml node can contains attributes which become a properties of qooxdoo widgets after translation. An attributes definition looks like: { ... "qx:tag" : { ... "attributes": { "*" : "path/to/template_all", "qxt:*" : "path/to/template_qxt", "command" : "path/to/template_command" } ... } } The configuration defined above means: 1) attribute with name "command" of a tag "qx:tag" will be processed with template "path/to/template_command" 2) attributes with namespace "qxt" of a tag "qx:tag" will be processed with template "path/to/template_qxt" 3) any other attributes of a tag "qx:tag" will be processed with template "path/to/template_all" 5) data - attributes default values (attr) and any properties (props) for tag 'data' structure contains 2 hash structures inside: { ... "qx:tag" : { ... "data":{ "attr": { "spacing":10 }, "props": { "class": "qx.ui.layout.HBox", "constructor-args": "spacing, alignX, separator" } } ... } 1) attr - attributes with predefined values. They merged at runtime with attributes defined in each particular node and will be available in template. For example (take a look at config above): if user doesn't define "spacing" attribute for qx:tag than will be used default value from configuration. 2) props - contains any other information related with tag, like constructor arguments, class name and any other. This information will be available in template as well. |
|
|
|
Documentation >
Mapping Configuration |