Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 13772 invoked from network); 7 Jun 2000 20:54:35 -0000 Received: from fw.infoplanning.net (HELO infoplanning.com) (@209.8.58.131) by locus.apache.org with SMTP; 7 Jun 2000 20:54:35 -0000 Received: (qmail 21224 invoked from network); 7 Jun 2000 19:56:02 -0000 Received: from unknown (HELO infoplanning.com) (192.168.0.189) by 192.168.0.138 with SMTP; 7 Jun 2000 19:56:02 -0000 Message-ID: <393EB516.F54E3251@infoplanning.com> Date: Wed, 07 Jun 2000 16:48:22 -0400 From: Berin Loritsch X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cocoon Dev List Subject: Code formatting thought... Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N I know this may be early to think about this now, but if we are doing server side compiling, why are we concerned about the format of the source code? In other words, if XSP is compiled behind the scenes and noone is really going to see the resultant code, why use a code formatter at all? The only reason I can think of is for debugging. But once an XSP page is properly debugged (and the system is properly debugged), then the JStyle code formatting becomes unnecessary overhead that only serves to increase the latency with the first access. Is there currently a way to turn it off for deployment? If not, will there be plans to do so? I suppose, if we also had a method to cause the site to detect (via sitemap) all the XSP pages and compile them on startup that this whole question becomes moot. Anyhoo, It's just a thought.