Dietrich - this is a very interesting idea and maybe you will want to
include your ideas once we have checked in the code. We are currently
waiting that the core developers find the time to help us integrate xslt
into the build process. I had proposed compiler options like this:
--xslt-use-stylesheet=/path/to/stylesheet.xsl \
--xslt-output-dir=/path/to/source/class \
--xslt-use-template-dir=/path/to/dir/containing/xml/templates,\
/path/to/dir/containing/more/xm/templates
and some attribute in the top-level widget node that indicates where the
generated javascript class code is to be put. The generated code is then
optimized and "compiled" with the rest of the source code. Earlier, the
concept was the on-demand generation of code, but that was not efficient
and depended on some php/java backend.
Cheers,
Christian
Dietrich Streifert wrote:
> In my current project I have used a bunch of xsl scripts which create a
> qooxdoo widget stack in javascript based on a xml schema. This widget
> stack is the "editor" for elements which are defined in the xml schema.
>
> The xml schema is also the base for generating the sql ddl code for the
> database and the code for the backend in perl.
>
> This xsl scripts also generate the field validation and the
> serialization code. One additional xml file is used to describe field
> dependencies and field calculations like enable field b if field a has
> value 'x' or value of field b is calculated form field c and field d. In
> most cases I've used a simple syntax for field dependencies like:
>
> <field name="a" input="radio">
> <enabled field="b" value="yes"/>
> </field>
>
> One of the main problems was how to identify a widget by its "name". To
> achieve this I've extended qx.ui.base.Widget whith some properties like
> xname and xpath which are used to "find" a widget by its name or xml
> path within a widget stack. This and a "name aware manager" which is
> attached to the top widget of the widget stack allowed to create code like:
>
> fielda.addEventListener("changeValue", function(e) {
> var fieldb = manager.getFieldByName("b");
> if(e.getData() == 'yes') {
> fieldb.setEnabled(true);
> }
> else {
> fieldb.setEnabled(false);
> }
>
> });
>
> The current schema contains 140 elements and the resulting editor widget
> has 140 input widgets like text fields, radio buttons and comboboxes
> which are grouped as tabs and group boxes. There are a lot of
> enabled/disabled dependecies between fields and fieldgroups. I think
> creating this logic by hand is very time consuming and faulty.
>
> I hink this task would have been easier with a qooxdoo xml layer between
> schema analyzation and widget creation. Maybe bringing in some
> additional functionality like widget dependencies and widget validation
> will give QxTransformer a competitive edge compared to handwired
> javascript logic.
>
> So I vote for QxTransformer.
>
>
> bishio schrieb:
>
>> Hi.
>>
>> I thing this is a great idea.
>>
>> A XSD schema for the xml can be helpful to develop external tools to create
>> and edit the xml-qooxdoo application.
>>
>> There are tools to design user interfaces, like glade, that save the
>> definition to xml files. It is possible to use that tools to create
>> interfaces for qooxdoo:
>> xml-glade->_xslt_->xml-qooxdoo->_xslt_>javascript_qooxdoo
>>
>>
>>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
