Return-Path: Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 15877 invoked from network); 1 Sep 2000 17:31:46 -0000 Received: from unknown (HELO ma7.webslingerz.com) (216.27.73.7) by locus.apache.org with SMTP; 1 Sep 2000 17:31:46 -0000 Received: by ma7.webslingerz.com (Postfix, from userid 501) id 5D129480F; Fri, 1 Sep 2000 13:34:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ma7.webslingerz.com (Postfix) with ESMTP id ECC096087 for ; Fri, 1 Sep 2000 13:34:35 -0400 (EDT) Date: Fri, 1 Sep 2000 13:34:35 -0400 (EDT) From: Donald Ball To: cocoon-users@xml.apache.org Subject: RE: Aha! got it! 64k limit(was: new version of the sql logicsheetunder development) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Fri, 1 Sep 2000, Torsten Curdt wrote: > > Only XSP that used DOM directly (AND WE TOLD YOU NOT TO DO IT!) will be > > hard to port, anything else will be piece of cake. > > Oh, oh! Nobody told _me_! Our JavaBeans produce DOM elements > and we insert them via XSP! So this is no longer possible in > Cocoon2?? if you're using to include the DOM elements, you _should_ be fine - it's only if you're manipulating the internal xsp DOM objects directly that you'll need to mess with anything. if for some reason, the XSP impl. for cocoon2 does _not_ let you include DOM objects via , i'll personally patch it so that it does. there are enough DOM2SAX convertors lying around that it would be absolutely inexcusable for us not to allow people to call libraries that return DOM objects. - donald