Hello Leander - thanks for your feedback which is very welcome. You are probably much more experienced with building application than me and your points are well taken. However, I think that there is a powerful case to make for xml-based widgets:
- as has been discussed before, they could ease the development of a GUI builder - they are much more readable than javascript code, thus far more easy to exchange between developers and way more easy to understand for newcomers - they speed up coding because xml is self-validating and keeps you from typos / hierarchy logic errors - they remove dependency of your code on changes in the underlying qooxdoo api and allow you to reuse code across qooxdoo versions You are correct that most of the event logic needs to be coded in javascript anyways and that this is the real stuff of development. However, I'd rather spend time on event logic and have the ease of XML instead of spaghetti xml code which does nothing but making instances of widgets, setting properties and adding the widgets to their parent widget... These are my 2eurocents.... ;-) Christian Leander Hanwald wrote: > Hello Siarhei > > To give you a feedback about prebuilding guis for qooxdoo (and I think > I'm not alone with it): > For mosts complex projects I think prebuilding of guis isn't very > important, when a projects got more complex many parts are based on own > written classes that are the main work todo, the building of the gui > part is simply not important. > When I write a class that handles a list of subobjects with different > states and co. the class writing need days (when it's complex), but > putting it on a form is extrem easy. > > Also I had never any problems putting a count of labels and edits on a > form, it's not that your way killed that job, it seems only be another > way to do that. > > In the past I often used RAD tools for DB Projects (mainly Delphi) and > they where very usefull for putting hundrets of stupid components > together, but when I wand to do a complex dynamic application where the > user can change the toolbar and menu, with forms that change there > content with the situation and so on. they where not very usefull anymore. > > It seems the same here for me, but only that using a transformer for my > code is not easier, also I have another step for to do (building the js > code from xml). > > You are right when you write "In addition, creation of UI based on XML > can be automated with visual GUI builder easier then based on JavaScript > code", but there are not so much around so far (only Delphi for PHP is > finished, right?) :-) > > Greetings, > Leander Hanwald > > Siarhei Barysiuk schrieb: > >> Hello, >> We haven't received any feedback about QxTransformer and integration >> into qooxdoo build >> process for a week and it gives a cause to say that this theme is not >> interesting for developers >> of qooxdoo. What a pity... It's really powerful idea. >> >> I've done work at documentation (draft version). You can find it at >> http://sourceforge.net/projects/qxtransformer (download section). >> Please, ask any questions if you need. >> >> Thanks, >> Siarhei Barysiuk >> >> Christian Boulanger wrote: >> >> >>> Hi Sebastian & others, >>> >>> any thoughts on the integration of xsl-templates into the compile >>> process? we want to get some work done during the weekend and it would >>> be good to know if this will be supported at all in the near future, at >>> least in SVN... >>> >>> Christian >>> >>> Christian Boulanger schrieb: >>> >>> >>> >>>> Hello! >>>> >>>> As I have mentioned before, Siarhei Barysiuk and I have been working on >>>> XSLT stylesheets which transform xml templates into qooxdoo javascript. >>>> This is a feature that is still missing from qooxdoo and would be very >>>> useful (The exisiting javascript Builder is ok, but far too slow, and >>>> not flexible in its design since it statically translates xml tags into >>>> class names). Siarhei has designed the architecture of the stylesheets >>>> very flexible. By using templates, arbitrary xml tags can be mapped to >>>> snippets of code which "implement" a certain widget. So it is possible >>>> even to have alternative xml syntaxes for the same widget to fit the >>>> developer's style. >>>> >>>> The whole system was initially designed for version 0.5 and worked quite >>>> well (see http://qxtransformer.sourceforge.net). Now we would like to >>>> adapt it to the upcoming version 0.7 and have a couple of questions. We >>>> don't know anything about the compile process (and won't have the time >>>> to learn about it) and therefore are dependent on the support of the >>>> core developers in integrating the xml->js generation process into the >>>> compile process. In particular, the developers would need to provide >>>> hooks and compile-time configuration options that enable us to integrate >>>> our work. >>>> >>>> One question is where the xml templates should be stored in the qooxdoo >>>> (skeleton) folder structure - this we happily leave to decide to the >>>> core developers. >>>> >>>> Another question is how the generated javascript object(s) should be >>>> integrated into the object hierarchy? One could think of having an >>>> attribute "classname" in the top-level widget like so >>>> >>>> <qx:window classname="custom.mynewwindow"> >>>> [all child widgets] >>>> </qx:window> >>>> >>>> This would then generate >>>> qx.Class.define ( "custom.mynewwindow", >>>> >>>> |{ >>>> extend : qx.ui.window, >>>> construct: function() >>>> { >>>> [here the main widget generation code is placed] >>>> } >>>> }); >>>> | >>>> >>>> and then the actual window would be called from Application.main: >>>> >>>> mynewwindow = new custom.mynewwindow(); >>>> mynewwindow.addToDocument(); // or this could go into the constructor >>>> >>>> Once this is done, one could even think of writing more stylesheets to >>>> transform xml produced by visual gui builders such as glade or >>>> qtdesigner (athough, of course, not everything can be mapped), or xul >>>> code. We think that would be an exciting prospect. >>>> >>>> We had started our own project at qxtransformer.sourceforge.net because >>>> at the time, it wasn't clear whether it was possible to contribute to >>>> the qooxdoo svn, and we certainly did not want to mail in patches for >>>> our own project. Once this is settled - I have heard that you are >>>> currently thinking about the issue - we can think about putting the code >>>> into the core svn. >>>> >>>> Siarhei is working on documentation so once the main questions are >>>> settled, we can restart the work and invite all interested developers to >>>> contribute.... >>>> >>>> Christian >>>> >>>> ------------------------------------------------------------------------- >>>> 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 >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> >>> >>> >> ------------------------------------------------------------------------- >> 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 >> >> >> >> > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
