Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 89690 invoked by uid 500); 12 May 2003 12:56:20 -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 89677 invoked from network); 12 May 2003 12:56:19 -0000 Received: from mailserver1.hrz.tu-darmstadt.de (130.83.126.41) by daedalus.apache.org with SMTP; 12 May 2003 12:56:19 -0000 Received: from paris (paris.dvs1.informatik.tu-darmstadt.de [130.83.27.43]) by mailserver1.hrz.tu-darmstadt.de (8.12.9/8.12.8) with ESMTP id h4CCtKbx016923 for ; Mon, 12 May 2003 14:55:20 +0200 Received: from bremen.dvs1.informatik.tu-darmstadt.de (bremen [130.83.27.69]) by paris (Postfix) with ESMTP id E79C2FF1A for ; Mon, 12 May 2003 14:55:19 +0200 (MET DST) Received: from haul by bremen.dvs1.informatik.tu-darmstadt.de with local (Exim 3.36 #1 (Debian)) id 19FCpr-0007an-00 for ; Mon, 12 May 2003 14:55:19 +0200 Date: Mon, 12 May 2003 14:55:19 +0200 To: cocoon-dev@xml.apache.org Subject: Re: _esql_connection.connection should be public Message-ID: <20030512125519.GG1227@bremen.dvs1.informatik.tu-darmstadt.de> Reply-To: haul@informatik.tu-darmstadt.de References: <3EBF4C7C.B5BA85B8@wincor-nixdorf.com> <3EBF65FD.10206@dff.st> <3EBF6AE6.EBA1CE7F@wincor-nixdorf.com> <3EBF720C.1080607@dff.st> <3EBF7AF0.1EF964B9@wincor-nixdorf.com> <3EBF815F.1020107@dff.st> <3EBF886E.46B11760@wincor-nixdorf.com> <3EBF8D35.3080805@dff.st> <3EBF9440.AD715414@wincor-nixdorf.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EBF9440.AD715414@wincor-nixdorf.com> Organization: Databases and Distributed Systems Group, Darmstadt University of Technology User-Agent: Mutt/1.5.4i From: Christian Haul X-MailScanner: Found to be clean X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 12.May.2003 -- 02:32 PM, Enke, Michael wrote: > Torsten Curdt wrote: > > > > > IMHO a new esql tag would be the best. > > > If we make it outside esql we have to care about all imports and try/catch > > > and what else is realted to java.sql.* in the xsp. This is not necessary when > > > we make it with esql. > > > If we create a new tag for returning the connection, I propose also to create a tag > > > for returning a ResultSet and ResultSetMetaData. > > > Than we have more freedom in manipulating/assigning all kind of DB related data. > > > > not sure if ResultSet and ResultSetMetaData is really necessary but... > > care enough for a patch? ;-) > > for variable asignment like: > > double d[] = new doubel[]; > for(int i=0;i > I can not say: d[i] = i > > Or can I? Yes, you can: d[i] = i BTW xsp:attribute adds an attribute to the output stream while you want to add an attribute to a logicsheet tag. Most - but not all - follow the pattern value Note that the logicsheet in question - and the tag in particular - needs to support dynamic values. Unfortunately, only an inspection of the xsl reveals what is supported and what isn't. Chris. -- C h r i s t i a n H a u l haul@informatik.tu-darmstadt.de fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08