Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 27000 invoked from network); 10 Oct 2005 15:17:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Oct 2005 15:17:25 -0000 Received: (qmail 88129 invoked by uid 500); 10 Oct 2005 15:17:10 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 87988 invoked by uid 500); 10 Oct 2005 15:17:08 -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 87722 invoked by uid 99); 10 Oct 2005 15:17:03 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2005 08:17:03 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of bloritsch@d-haven.org designates 69.59.195.20 as permitted sender) Received: from [69.59.195.20] (HELO pyramid-01.kattare.com) (69.59.195.20) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2005 08:17:04 -0700 Received: from [127.0.0.1] ([66.208.37.51]) (authenticated bits=0) by pyramid-01.kattare.com (8.12.11/8.12.11) with ESMTP id j9AFGbbe019650 for ; Mon, 10 Oct 2005 08:16:40 -0700 Message-ID: <434A85CC.4040503@d-haven.org> Date: Mon, 10 Oct 2005 11:16:28 -0400 From: Berin Loritsch User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Reality Check (was Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Max Pfingsthorn wrote: >The "handleControllerCall" function can be written in flowscript or even use the great new java flow as shown by Torsten Curdt during the get together. Not sure how that class reloading works, but if you put the controller classes in the same path, I guess the reloading feature would work there as well. So, you can do something like...: > >if(action==null) action="index"; >contr = Package.org.apache.cocoon.util.ClassUtils.newInstance("controllers."+controller+"Controller"); > >if(id==null) > contr[action](); >else > contr[action](id); //well, a little more processing here to get the object with this id first > >cocoon.sendPage("views/"+controller+"/"+action); > >Right? > >max > > One of the nice features of the Rails implementation is the fact that a class method maps to an action. It makes the code very easy to test, and therefore very appealing. Think about it, if you were going to write a unit test, would you rather invoke a scripting engine or simply execute against a class? Also, the inherent simplicity of concepts where a developer can leverage the Java skills that they already have is very enticing. The controller would essentially inherit a base class that takes care of the reflective resolution of the actions, and all is well. It just works. My major complaint against flowscript isn't the concept--its the feeling that I am flying without a net. I don't have a convenient way of testing the javascript. I can't use an IDE to make things even easier. There is something to be said for using the autocomplete function of your favorite IDE as apposed to trying to remember how everything is mapped to the FOM. Again, why should the developer have to type out cocoon.sendPage(...) when the sitemap implementation takes care of it for you.