From cocoon-dev-return-37694-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Tue Mar 04 19:03:36 2003 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 23364 invoked by uid 500); 4 Mar 2003 19:03:36 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 23351 invoked from network); 4 Mar 2003 19:03:35 -0000 Received: from unknown (HELO zeus.hapra.at) (212.52.194.171) by daedalus.apache.org with SMTP; 4 Mar 2003 19:03:35 -0000 Received: from [172.16.1.33] ([62.46.242.111]) by zeus.hapra.at with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Mar 2003 20:01:00 +0100 Subject: Re: Stabilizing flow in order to release From: Jakob Praher To: cocoon-dev@xml.apache.org In-Reply-To: <3E64E7F7.3040406@verizon.net> References: <3E645F29.4030007@apache.org> <3E648055.70203@anyware-tech.com> <3E648358.7030305@apache.org> <3E64E7F7.3040406@verizon.net> Content-Type: text/plain Organization: Message-Id: <1046804325.2304.170.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 04 Mar 2003 19:58:45 +0100 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 19:01:00.0906 (UTC) FILETIME=[65A8FCA0:01C2E280] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Am Die, 2003-03-04 um 18.52 schrieb Christopher Oliver: > Not sure. This is one of the weaknesses of JavaScript. It doesn't have > any structuring mechanism for creating libraries or reusable modules > (which was one of the things JavaScript 2.0 was supposed to fix). I > think Cocoon will have to invent its own mechanisms to describe and > manage script libraries. the mozilla folks do many complex things in javascript, to avoid using c++ too often ;-) so perhaps they have settled on something which could be useful to cocoon here. there are some jslib things at mozdev.org. I could also imagine using SourceResolvers like in the sitemap here. Like include( 'js:/x/y/z.js' ) or import( 'js:/x/y/z.js' ) whereas import does not override existing declarations and include is just a cut'n paste of it. include and import woud simply be FunctionObjects that get bootstrapped at initialization time. they take a String as a parameter and hand this to a SourceResolver, which in turn knows how and where to load it from. just my 2 cents. btw: does anyone know if Norris Boyd or others are working on a JS 2 / EcmaScript4 Version in java - in cvs.mozilla there exists only a cpp impl of js2... -- Jakob