Re: attribute initialization
On Thu, 28 Feb 2002, Thomas Colin de Verdiere wrote: if we had : mytags:MyTag attr1=true/ //first mytags:MyTag/ // second instance then for the second instance attr1 is not false but true : as the container could use MyTag first instance from the first instanciation. This is a very good question to ask, but it's actually based on an incorrect assumption. The container cannot reuse the same MyTag instance from the first invocation to the second, precisely because its set of attributes is different. Section JSP10.1.1 in the JSP 1.2 spec says the following: tag handlers can only be reused within the same AttSet (set of attributes that have been set). If my memory is correct, the question you ask is exactly the reason that the spec lays out this requirement: if it didn't, you'd have no place to sensibly initialize default values for subsequent invocations that used fewer attributes than their predecessors. The practical answer is, thus, You don't need to worry about it. Initializing the instance variable as boolean attr1 = false; is fine. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: attribute initialization
Thank you so much Shawn Shawn Bayern wrote: On Thu, 28 Feb 2002, Thomas Colin de Verdiere wrote: if we had : mytags:MyTag attr1=true/ //first mytags:MyTag/ // second instance then for the second instance attr1 is not false but true : as the container could use MyTag first instance from the first instanciation. This is a very good question to ask, but it's actually based on an incorrect assumption. The container cannot reuse the same MyTag instance from the first invocation to the second, precisely because its set of attributes is different. Section JSP10.1.1 in the JSP 1.2 spec says the following: tag handlers can only be reused within the same AttSet (set of attributes that have been set). If my memory is correct, the question you ask is exactly the reason that the spec lays out this requirement: if it didn't, you'd have no place to sensibly initialize default values for subsequent invocations that used fewer attributes than their predecessors. The practical answer is, thus, You don't need to worry about it. Initializing the instance variable as boolean attr1 = false; is fine. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
debugging query text for DBTags
It seems there is no way to print out a query between query tags without first assigning a query to a string variable, then printing that variable out later. This is extremely important when slightly complicated queries are being dynamically generated (changing, WHERE or GROUP BY clauses, etc.). It would be nice if there was an option of printing out the final text of the query (the way it will be sent over the JDBC driver). It may be as simple as making the query variable public, or having a tag (put AFTER the query tags) that prints out our sql query. I am not very familiar with the java code that goes into making tag libraries, especially DB tags. If there is someone who can work on it, I think that will be perfect. If this is something that might make it into the distribution fairly quickly, but no one is willing to work on it, I can start to dig into the code. Shahbaz DISCLAIMER This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify me and permanently delete the original and any copy of any e-mail and any printout thereof. NOTICE REGARDING PRIVACY AND CONFIDENTIALITY Knight Securities may, at its discretion, monitor and review the content of all e-mail communications. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: debugging query text for DBTags
Shahbaz, If you would rather use existing tags to do this instead of scriptlets, you could set an attribute at page scope using the Page taglib and then print it. To make the printing more dynamic, I believe you could use the Application taglib to check for an initialization parameter, and then make the printing of the attribute conditional upon the existence of the parameter. If you want to make this a design request for the taglib, you might want to address the taglibs-dev discussion list. The taglib developer may see your post and start a dialog about your request. Regards, Garrel Renick -Original Message- From: Chaudhary, Shahbaz [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 28, 2002 3:10 PM To: '[EMAIL PROTECTED]' Subject: debugging query text for DBTags It seems there is no way to print out a query between query tags without first assigning a query to a string variable, then printing that variable out later. This is extremely important when slightly complicated queries are being dynamically generated (changing, WHERE or GROUP BY clauses, etc.). It would be nice if there was an option of printing out the final text of the query (the way it will be sent over the JDBC driver). It may be as simple as making the query variable public, or having a tag (put AFTER the query tags) that prints out our sql query. I am not very familiar with the java code that goes into making tag libraries, especially DB tags. If there is someone who can work on it, I think that will be perfect. If this is something that might make it into the distribution fairly quickly, but no one is willing to work on it, I can start to dig into the code. Shahbaz DISCLAIMER This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify me and permanently delete the original and any copy of any e-mail and any printout thereof. NOTICE REGARDING PRIVACY AND CONFIDENTIALITY Knight Securities may, at its discretion, monitor and review the content of all e-mail communications. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
