[DRAFT] In the following, I document the major changes. 1) Rework qxtransformer core and rewrite it in Python The existing XSLT implementation in v. 0.3 works perfectly without any problems and the existing design allows extending it simply. However, as noted above, the dependency on xsltproc and make makes its use difficult for Windows users. in addition, XSLT has some disadvantages. It is not easy to transform only parts of the code (i.e. one input xml, one output js file), working with string, etc. XSLT ist also harder to maintain than regular code (even despite of our documentation plugin). I come up with the following: a) Using Python for core The qooxdoo tools written in Python and no additional dependencies. b) Using Mako Templates for writing templates (http://www.makotemplates.org/) Mako templates are very fast and fairly easy to understand for new users. Also they can contain a pure Python code which make it even more flexible. More information(as well as performance comparison) can be found on official site. c) Using lxml for processing xml Python has built-in support for processing xml - Element Tree, but it has very limited XPath support, what is very important for qxtransformer. lxml has the same API as Element Tree and has very strong XPath support . It uses libxml2 and libxslt libraries. The main disadvantage is adding a new dependency, Windows users have no libxml2 shipped with OS, but the windows version of this library has all necessary binaries bundled. lxml performance is very good too (performance tests). 2) Provide easier way to extend and add new tags The new version of qxt provides a simpler way to extend the core library and add new tags and functionality. There are two ways this can be done. a) Adding a new syntax There are similar declarative approaches like XUL, Qt .ui XML and others. It allows to use existing infrastructure for these formats and produce qooxdoo javascript. The toolkit will support this approach, but it won't be a priority of the project. We will promote the "native" qxml format which is specially designed and optimized for qooxdoo. The reason is that each declarative language has a whole architectural philosohpy attached to it and dependencies on the underlying API that a direct transformation works only in the most trivial UI designs. b) Extending an existing syntax and adding new tags There are a lot of good projects in qooxdoo-contrib which provide good widgets for users. It's very easy to add it to your project just in configuration. There will be a way to allow to add declarative description into qxtransformer as simple as adding new components from qooxdoo-contrib to your project. A developer of qooxdoo-contrib extension canl provide some description for new tags in package and qxtransformerwill automatically handle them, analyze and register new tags. After this you will be able to use xml tags in qxml for newly added components. 3) More readable templates and simpler configuration Qooxdoo uses json format for configuration files. It is easy for humans to read and write. QxTransformer will use json for own configuration files as well. Mako templates has very simple syntax, easy enough so people can start writing their own templates 4) Possibility to use it inside of other application and do on-the-fly transformation We are evaluating ways to embed qxt within another application or to use it as a backend for on-the-fly transformations for requesting clients. However, this is currently not priority, because all real-life examples require optimization (which tools do at build phase). But it could be handy for autogenerated things like forms, polls, etc. If you have use cases for this feature, let us know. |
|
|
|
Documentation >
Changes in 0.4 version |