Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 75997 invoked from network); 24 Nov 2004 11:02:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 24 Nov 2004 11:02:14 -0000 Received: (qmail 48576 invoked by uid 500); 24 Nov 2004 11:01:59 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 48297 invoked by uid 500); 24 Nov 2004 11:01:55 -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 Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 48174 invoked by uid 99); 24 Nov 2004 11:01:54 -0000 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 (hermes.apache.org: domain of ap-cocoon-dev@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from main.gmane.org (HELO main.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 24 Nov 2004 03:01:51 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CWuoB-0002ab-00 for ; Wed, 24 Nov 2004 11:55:35 +0100 Received: from dyn-213-36-224-121.ppp.tiscali.fr ([213.36.224.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Nov 2004 11:55:35 +0100 Received: from t.katelbach by dyn-213-36-224-121.ppp.tiscali.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Nov 2004 11:55:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: dev@cocoon.apache.org From: oceatoon Subject: Re: Client side validation Date: Wed, 24 Nov 2004 12:05:31 +0100 Organization: oceatoon Lines: 29 Message-ID: References: <41A223DF.3090006@apache.org> <41A26BD1.1030501@apache.org> <41A2F14D.6000907@apache.org> <0A1DF444-3D3F-11D9-B36C-000A95AF004E@apache.org> Reply-To: t.katelbach@systheo.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dyn-213-36-224-121.ppp.tiscali.fr Mail-Copies-To: t.katelbach@systheo.com User-Agent: KNode/0.8.0 Sender: news X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Bertrand Delacretaz wrote: > Le 23 nov. 04, � 10:53, oceatoon a �crit : >> ...Is different JS really coded for different browsers? I thought >> there were >> only those with JS and those without, in the second case validation >> would >> go back to Server Side but no different version of scripts... > > your (future) client might *not* even be a browser per se. Think Flash, > XUL, and related stuff. thanks for putting it back into the real Cocoon context of abstraction which us multiple final layouts, I sometimes get cornered in my use case,the web. But please correct me I might be completly off track, but if the entier snippets are written directly as blocks of code, specific to "one" final result ( otherwise resutl specific validations are needed) , these could concirn as much actionscript for Flash, i don't know much about XUL but also for it's own language. and the validation would still be functionnal. IMHO, it is easier to produce the validation(complex or complex) in the code we are actively using (coding). Adding more layers of abstraction seems a complication (I dear to say) that is justified when multiple types of finale results use one same validation rule translated into each of it's specific codes. These solutions being in no way blocking for one another, I hope they both find there way ;) Regards Tibor