hello, you might remember my bringing up this issue some time ago. here it is again.
i think that the qx.io namespace must be redesigned, and the qx.io2 namespace should be unified with qx.io (or should be renamed to something else because it sounds too much like an ugly hack.) before freezing the api. here are some issues, from my point of view: 1) qooxdoo must be able to support additional backend-communication protocols. if it ever does, the most elegant way to do this is to have classes like qx.io.rpc.Json, qx.io.rpc.Xml (xmlrpc) qx.io.rpc.Soap, etc. You may have noticed my reluctance to use jsonrpc. it's cute and compact and all, but it lacks some important features like security, routability, authentication, etc. so i don't think it is up to par with today's enterprise requirements. So pushing JsonRpc as the one-size solution for backend queries renders qooxdoo less flexible than it is ought to. Without taking the anti-rest propaganda seriously, you can read the following article with better explains reasons for my support of soap as a backend-communications protocol: http://wisdomofganesh.blogspot.com/2007/12/paying-restafarians-back-in-their-own.html i'd also like to note that the soap protocol has great server-side support -- you don't need to roll your own. so, in short, i'm pretty sure that leaving room for other communication protocols will certainly add to the value of qooxdoo. 2) all those hypothetic classes should inherit from a common qx.io.IRpc a common rpc protocol interface. this will let us switch between different protocols with a minimum amount of effort. 3) I think that the qx.ui.table.Table is a great idea, well executed. Two points here: a) The "qx.ui.table.model" and "qx.ui.table.columnmodel" name spaces don't communicate their purposes precisely enough. i'd prefer to rename them to qx.ui.table.datasource and qx.ui.table.dataschema respectively. maybe better names could be suggested. b) The functionality of remote models could be applied to anything that scrolls. Comboboxes, Listboxes, and the like could benefit from such an abstraction. This also would make implementing an interface that "brings suggestions while the user is typing" a breeze. i guess this sums my thoughts up. i could file those separately as three (four?) bug reports if you want me to. awaiting your feedback best regards, burak ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
