From dev-return-82566-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Dec 07 15:57:30 2005 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 83445 invoked from network); 7 Dec 2005 15:57:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Dec 2005 15:57:23 -0000 Received: (qmail 44868 invoked by uid 500); 7 Dec 2005 15:57:11 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 44804 invoked by uid 500); 7 Dec 2005 15:57:10 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 44793 invoked by uid 99); 7 Dec 2005 15:57:10 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2005 07:57:10 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [84.96.21.10] (HELO mail.anyware-tech.com) (84.96.21.10) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2005 07:57:09 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.anyware-tech.com (Postfix) with ESMTP id D1226339D2 for ; Wed, 7 Dec 2005 16:56:47 +0100 (CET) Received: from mail.anyware-tech.com ([127.0.0.1]) by localhost (trinity [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06158-08 for ; Wed, 7 Dec 2005 16:56:44 +0100 (CET) Received: from [10.0.0.27] (poukram.anyware [10.0.0.27]) by mail.anyware-tech.com (Postfix) with ESMTP id 0BC08339CE for ; Wed, 7 Dec 2005 16:56:44 +0100 (CET) Message-ID: <4397063B.2000501@apache.org> Date: Wed, 07 Dec 2005 16:56:43 +0100 From: Sylvain Wallez User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done) References: <4395CA8F.6020405@d-haven.org> <439690E2.4000506@apache.org> <439698EC.8060803@apache.org> <1BD38A83-0648-4205-991F-F0A5FAD87223@apache.org> <4396F05D.9030106@d-haven.org> In-Reply-To: <4396F05D.9030106@d-haven.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at anyware-tech.com X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Berin Loritsch wrote: > In the exchange below I did some creative snipping to emphasize where > we are not 100% aligned on vision. Below I will bring out my points, > knowing that I'm not the guy who sets the tone for Cocoon. We are collectively setting the tone, and your inputs are very valuable! > I can infer from Sylvain's vision that he sees value in using > JavaScript on the server as well as on the cient. And why not? We > have the solution already in place. Yep. Several reasons for this: - JS provides a more concise writing, which is great when you write the glue code of your application, - my experience is different than yours, as I've seen many people using Cocoon being unable to write a Java class but perfectly able to write a flowscript to drive page flow, display forms and glue components together. > Now, the Pros of using JavaScript that I can see are as follows: > > * Common syntax on server and client > * Easy to use Java objects in JavaScript code > * Easy to add support for continuations > > The cons I see are as follows: > > * API depends on bound objects (not consistent between client and server) Yep. Now stuff like JSON [1] can allow for *very* easy client/server communications in Ajax scenarios. > * No testing framework for JavaScript Code People writing Ajax libraries are getting serious about unit tests. Have a look at [2] and [3]. > * Requires embedding a JavaScript runtime in the server Rhino will be embedded in JDK 1.6 (or whatever its name) > * We can't use the same debugger in our IDE to step through server > side JavaScript code Right. > * No IDE support for JavaScript There's a JS plugin in Eclipse webtools and the amazing JSEclipse [4] that does autocompletion of function and argument names, plus tooltips and all that stuff. It even accepts additional completion description files that we could generate automatically from the API that we expose to the JS engine. > * It's another language to have to learn Yeah, but a language that many people already now. > The testing framework for JavaScript is easily overcome. We could > create something to get that working. In Java 6 (still being worked > out) JavaScript is supposed to be embedded into the core, so when the > IDEs tool for Java 6, my objections involving IDE and debugger will go > away--but that is a ways off still. Which leaves us with the API con > and the learning con. > > I will stick to my guns for my belief that JavaScript will fail in its > mission to bring "less technical" people to work on the server side. > Less technical people need all the handholding they can get, so > without IDE support and a well defined API they won't know what to > do. That does not mean that JavaScript is evil, or that it doesn't > have a place on the server or in Cocoon. I just think we are kidding > ourselves if we think it will allow less technical people to do a > programmer's job. Again, I have seen semi-technical people doing great things with JS. Not all the bells and whistles of the full J2EE stack, but some fairly advanced stuff they could never have done with only the Java API (nor PHP, btw). So the flow controller is really a place (and the *only* one actually) where I value having two implementations, one in Java and one in JS. However, these two implementations should really be a very thin layer on top of a common controller infrastructure, both to reduce the effort and ensure long-term consistency. > What's your preference for the vision? > > [ ] All web apps written in JavaScript > [ ] All web apps written in pure Java > [X] Mix and match (not as simple, but is status quo with today) Sylvain [1] http://www.crockford.com/JSON/ [2] http://archive.dojotoolkit.org/nightly/testtools/ [3] http://www.edwardh.com/jsunit/ [4] http://www.interaktonline.com/Products/Eclipse/JSEclipse/Overview/ -- Sylvain Wallez Anyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director