One other option is to roll the backends INTO the Qooxdoo framework
distribution so that they are always supplied with the appropriate
Qooxdoo version - why do they need to be kept as contributions? From
time to time, contributions are combined into the Qooxdoo mainstream
distribution, aren't they?
It seems the coupling between the client and backend components is
critical enough that they should be supplied together when a developer
retrieves Qooxdoo. In the case of the backends, all the developers are
participants on this mailing list. Just create an additional folder in
the distribution for backend servers and dump them all into Qooxdoo.
Since the backend development is maintained by various Qooxdoo
developers in parallel with the Qooxdoo client development path, this
allows the matching backend code to be kept in sync at all times. The
only time a contribution arrangement is required is when a new backend
server is being developed and needs incubation time to become
production-ready. Once they are being used in production situations, it
makes sense to provide them with the Qooxdoo framework.
Along the same lines, maybe it's time for the RpcExample and RpcConsole
to also become a part of the Qooxdoo distribution. All of these
components related to development of Qooxdoo apps that depend on a
server backend are becoming more important for developing just about any
mainstream web app - how many of us are developing client apps without
any type of backend component?
Are there more pressing reasons to keep the backend components separate
from the client framework? How much would this grow the framework size?
Just my 2 cents,
Gene
On Sat, 2009-11-28 at 08:20 +0100, 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
>
> plain text document attachment (RpcJava-1.0beta1-patch.txt)
>
> 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
------------------------------------------------------------------------------
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
