3 Jul 16:09
qx.ui.table.model.Simple.setSortMethods()
From: Ian Horst <ian.horst <at> googlemail.com>
Subject: qx.ui.table.model.Simple.setSortMethods()
Newsgroups: gmane.comp.lang.javascript.qooxdoo.devel
Date: 2009-07-03 14:12:20 GMT
Subject: qx.ui.table.model.Simple.setSortMethods()
Newsgroups: gmane.comp.lang.javascript.qooxdoo.devel
Date: 2009-07-03 14:12:20 GMT
I wonder why there are 2 sort methods, one for ascending, second for descending. It's enough to define ascending sort method. Descending is just reverse of ascending sort method. ascending: ascSortMethod(); descending: - ascSortMethod(); --- Ian ------------------------------------------------------------------------------
>>
>> I'm almost done with configuring the Qooxdoo toolchain (manifest +
>> config) for eating a more standard maven project layout (e.g.
>> src/main/js, src/main/resources, target/, ...) and the next step
>> constists in allowing the developer to do as little manual setup as
>> possible on the build machine.
>> I dropped the idea of running the build with Jython since I could'nt
>> get
>> it right (the "maximum recursion depth" problem). So I made my mind on
>> using a normal python interpreter so this one will have to be manually
>> installed if not already there (M$...). So far, so good.
>>
>> The question is now to have the java RPC backend packaged and deployed
>> as a Maven artifact (a jar containing the compiled classes) for later
>> inclusion as a dependency in the Maven built WAR. I can manage to
>> build
>> the JAR from the contrib source code and my proposition is to host the
>> resulting unmodified archive into the Jspresso Maven repository so
>> that
>> it gets publicly accessible to the build. I think that the license
>> allows it but I would like to hear that you don't have any objection
>> against it.
>>
>> Same goes for the Qooxdoo framework and toolchain. The idea I have
>> is to
>> make a "light" zip archive of Qooxdoo that would only contain the
>> framework JS files + resources + python toolchain (I would mainly get
>> rid of the "application" and "component" directories). Then again, I
>> could host it into the Jspresso Maven repository so that it would get
>> automatically downloaded, unpacked and used during the build of a
>> Jspresso application. Of course this Qooxdoo artifact will be
>> versioned
>> (0.8.2, 0.8-SNAPHOT, ...) so that a target application build can run
>> against a predefined Qooxdoo release depending on what has been
>> declared
>> into the project POM file. Same question than before : any objection /
>> licensing issue against it ?
>>
>> If you don't see any showstopper for both points, I think I can manage
>> to seamlessly integrate the Qooxdoo build into the Jspresso Maven
>> build
>> with only python as a requirement. Of course, all licensing, IP, site
>> reference informations would be retained in both deployed artifacts.
>>
>> Thanks in advance,
>> Vincent
>>
>> --
>> Vincent Vandenschrick
>> Jspresso Framework
>> 
RSS Feed