Return-Path: Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list taglibs-dev@jakarta.apache.org Received: (qmail 85348 invoked from network); 26 Dec 2000 16:47:46 -0000 Received: from unknown (HELO ntserver.nevada) (213.96.183.15) by h29.sny.collab.net with SMTP; 26 Dec 2000 16:47:46 -0000 Received: by ntserver with Internet Mail Service (5.0.1457.3) id ; Tue, 26 Dec 2000 17:47:38 +0100 Message-ID: <80F5674514B4D311BAFC0040F6A45EEE0BE24D@ntserver> From: Nacho To: "'taglibs-dev@jakarta.apache.org'" Subject: RE: SQL tags Date: Tue, 26 Dec 2000 17:47:33 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain X-Spam-Rating: h29.sny.collab.net 1.6.2 0/1000/N Hola a todos: (Please do not use HTML when post to lists, it's makes conversations almost impossible ) The SQL taglib was that you comment, a toy implementation, usefull to learn, nothing more was pretended with that, at least from myself.. I think will be better to use the"sql" Taglib subproyect to something more usefull and better implemented than the actual SQL taglib, +1in do whatever you think it's usefull to the actual SQL taglib. I think that a SQL taglib it's really useful. What do you want to do to the query tag? Saludos , Ignacio J. Ortega -----Mensaje original----- De: mdelagra@us.britannica.com [mailto:mdelagra@us.britannica.com] Enviado el: martes 26 de diciembre de 2000 17:22 Para: taglibs-dev@jakarta.apache.org Asunto: SQL tags Hi all, So, for several months now, I've been using my own set of custom tags to perform SQL operations. I'd like to contribute them, but I'm not sure how to proceed. Jakarta-taglibs already has a SQL taglib, but it's a "toy" implementation designed to demonstrate a particular portion of the JSP spec, not a general API to SQL. Can we create a new subproject with a more generally useful SQL implementation? Or is it better to simply replace the current SQL project? I can reuse most of what is in the current taglib, but I would want to use the tag "query" for something else. Perhaps we could keep that class in the code and just alias it with another name. Boyd Waters and Ignacio J. Ortega should definitely weigh in here, since they implemented the original taglib. Or perhaps we could move the current sql taglib subproject to another location to make room for this new subproject? Or is a taglib for SQL not generally desired? - Morgan