Return-Path: Delivered-To: apmail-jakarta-taglibs-dev-archive@apache.org Received: (qmail 77661 invoked from network); 23 May 2002 19:24:11 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 May 2002 19:24:11 -0000 Received: (qmail 13010 invoked by uid 97); 23 May 2002 19:24:12 -0000 Delivered-To: qmlist-jakarta-archive-taglibs-dev@jakarta.apache.org Received: (qmail 12988 invoked by uid 97); 23 May 2002 19:24:12 -0000 Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tag Libraries Developers List" Reply-To: "Tag Libraries Developers List" Delivered-To: mailing list taglibs-dev@jakarta.apache.org Received: (qmail 12972 invoked by uid 98); 23 May 2002 19:24:11 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Reply-To: From: "Steve A. Olson" To: "'Tag Libraries Developers List'" Subject: RE: Startard Taglib- SQL bind variables Date: Thu, 23 May 2002 15:23:46 -0400 Message-ID: <004e01c2028f$5c960670$6e00a8c0@epic.aitinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <004d01c2028e$da0b9940$6e00a8c0@epic.aitinc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N All, ... sql attribute already exists, sorry about item 2. Would just note that bind variables would be allowed there as well. --Steve -----Original Message----- From: Steve A. Olson [mailto:steve.olson@ait-inc.com] Sent: Thursday, May 23, 2002 3:20 PM To: 'Tag Libraries Developers List' Subject: Startard Taglib- SQL bind variables I'd like to propose an alternate syntax for binding variables to SQL statements in the Standard SQL taglib. 1- Instead of using nested "param" tags that match a corresponding "?" placeholder, allow developers to directly embed variables into the sql string. Depending on the complexity of the parsing it may be easier to use "colon" variables instead of "$" variables-- I'm not sure about that. 2- Additionally, I'd like to propose an "sql" attribute that could be used in-lieu of the tag body; again, for reducing extraneous text. Here is an example of the proposed syntax: UPDATE account SET Balance = Balance - $transferAmount WHERE accountNo = $accountFrom Again, using the sql attribute: *BTW, I'm not sure if line breaks are allowed within attribute assignments, however, it makes for more readable code. Again, using current syntax: UPDATE account SET Balance = Balance - ? WHERE accountNo = ? Finally, with this simplified syntax, we can collapse all of the tags required to implement a prepared query into a single concise tag as follows! (I find this syntax much more usable and far less "wordy".) <%-- body processed for each fetch in resultSet ... --%> I look forward to your comments. -- Steve Olson steve@ait-inc.com -- To unsubscribe, e-mail: For additional commands, e-mail: