Hi all, not being a java person, it seems nontheless imperative to me that an updated and unified Java backend, together with some decent and up-to-date docs should accompany the qooxdoo 1.0 release. Everything else - at least that would be my impression - would be unfortunate and unneccessarily deterrent for first-time qooxdoo/java users.
If have moved some java documentation from http://qooxdoo.org/documentation/0.8/rpc to http://qooxdoo.org/documentation/0.8/rpc_java but I don't know if the code there still applies. Can someone look into it and fix the documentation? Other than that, it would be great if the code of the Java servlet could be updated, too - who is in charge here? ;-) Thanks, Christian Vincent Vandenschrick wrote: > > Hi all, > > Regarding RPC backends, there is another point that I would like to > raise to your attention. My use of RpcJava with latest Qooxdoo releases > forced me to change the codebase to make it work. This is due to API > change (e.g. qx.io.ScriptTransport removed in 1.0-beta1, after a > deprecation period). > Identifying and fixing the code is not a problem by itself, but how to > maintain it, i.e. what should go into SVN ? If we check-in the change, > it breaks pre-0.8 implementations, and if we don't, then it doesn't work > with 1.0+. > > > I see 2 main options (variations could be made) : > > * keep a single SVN branch (the trunk) but introduce an indirection > through some strategy/delegation pattern to isolate the code that is > tightly coupled to the Qooxdoo version of the client-side (the > server-side JS generation). Then find a way to instanciate the good > strategy based on the Qooxdoo version : > - automatically : if there is a way for the client to send its Qooxdoo > version when initiating the communication. This would enable support for > heterogenous Qooxdoo clients within the same server. > - by external configuration : at server startup (e.g. a servlet > parameter for RpcJava, don't know for others). Easier but less flexible > than the previous one, i.e. only 1 Qooxdoo version supported per server > instance. > > * setup a clean and uniform branching/tagging policy for contributions. > This is true for RpxcXxx but somehow even more important for Qooxdoo > contribs that are to be included in the build using the "contrib:/" URL > scheme. Linking to a contrib trunk is dangerous, especially when the > contribution is quickly evolving and follows the latest Qooxdoo API. > This makes the builds of a Qooxdoo app not reproductible and a good > branching/tagging policy would at least solve this problem. > > BTW, find attached the SVN patch applied to my local RpcJava check-out > to make it 1.0-beta1 compliant. > > Best, > Vincent > > Index: rpc/net/sf/qooxdoo/rpc/RpcServlet.java > =================================================================== > --- rpc/net/sf/qooxdoo/rpc/RpcServlet.java (revision 19559) > +++ rpc/net/sf/qooxdoo/rpc/RpcServlet.java (working copy) > @@ -204,13 +204,15 @@ > propertyType)); > } catch (Exception e) { > // try to instatiate a class of the supplied > parameter > - System.out.println("***** setting '" + > propertyName + "' to an instance of '" + initParamValue + "'"); > + // System.out.println("***** setting '" + > propertyName + > + // "' to an instance of '" + initParamValue + > "'"); > PropertyUtils.setSimpleProperty(inst, > propertyName, > getServiceInstance(session, > initParamValue, null, null)); > } > } > } else { > - System.out.println("***** property '" + propertyName > + "' not matched"); > + // System.out.println("***** property '" + propertyName > + > + // "' not matched"); > } > } > > @@ -269,7 +271,7 @@ > > private String makeJavaScriptServerInfo(HttpServletRequest request) { > return "if (!qx || !qx.core || !qx.core.ServerSettings) {" + > - "qx.OO.defineClass(\"qx.core.ServerSettings\");" + > + "qx.Class.define(\"qx.core.ServerSettings\");" + > "}" + > "qx.core.ServerSettings.serverPathPrefix = \"" + > getContextURL(request) + "\";" + > "qx.core.ServerSettings.serverPathSuffix = > \";jsessionid=" + request.getSession().getId() + "\";" + > @@ -407,7 +409,7 @@ > //System.out.println("Requested session id: " + > request.getRequestedSessionId()); > String res = handleRPC(request, requestString); > > - > responseWriter.write("qx.io.remote.ScriptTransport._requestFinished(\"" + > + > responseWriter.write("qx.io.remote.transport.Script._requestFinished(\"" + > jsTransportId + "\", " + res + ");"); > } > } catch (Exception e) { > @@ -460,7 +462,7 @@ > requestBuffer.append(readBuffer, 0, length); > } > String requestString = requestBuffer.toString(); > - System.out.println("Request string: " + requestString); > + // System.out.println("Request string: " + > requestString); > res = handleRPC(request, requestString); > } > > > ------------------------------------------------------------------------------ > 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 > > -- View this message in context: http://n2.nabble.com/Rpc-backend-harmonization-tp4075821p4079172.html Sent from the qooxdoo mailing list archive at Nabble.com. ------------------------------------------------------------------------------ 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
