sql, choose and scope
A problem about scope:
my script
c:choose
c:when test=${param.sqlRequest == 1}
sql:query var=flashRecordSet
SELECT ID_news,data,
titolo_it as titolo,
abstract_it as abstract,
testo_it as testo
FROM tb_news
/sql:query
/c:when
/c:choose
Result rs = (Result)pageContext.findAttribute(flashRecordSet);
I can't find flashRecordSet. If SQL tag is out the tags Choose and When
all work fine.
Some one can explain me why? I need just the path to get flashRecordSet
thanks Lorenzo Sicilia
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: sql, choose and scope
I suspect the body of the when clause is not executed
because its condition evaluates to false.
You should print the value of param.sqlRequest prior
to the c:choose to make sure it has the value 1.
-- Pierre
Lorenzo Sicilia wrote:
A problem about scope:
my script
c:choose
c:when test=${param.sqlRequest == 1}
sql:query var=flashRecordSet
SELECT ID_news,data,
titolo_it as titolo,
abstract_it as abstract,
testo_it as testo
FROM tb_news
/sql:query
/c:when
/c:choose
Result rs = (Result)pageContext.findAttribute(flashRecordSet);
I can't find flashRecordSet. If SQL tag is out the tags Choose and When
all work fine.
Some one can explain me why? I need just the path to get flashRecordSet
thanks Lorenzo Sicilia
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: EL in String Taglib 1.0
Hi Travis, String Taglib [and all the Jakarta taglibs to my knowledge] are not ELized yet. JSP 2.0 will make all taglibs ELized, so the question on whether to add hacked in support for ELs to the taglibs is a bit up in the air depending on when JSP 2.0 is released, and how long this is going to be before it's released [I thought it would be soon, but hard to tell sometimes]. The current nightly builds are pretty similar to your version, the only difference being a big bug-fix for using the taglib inside a loop [probably only occurs in certain servers] and the addition of a new attribute to the Replace tag [for handling newlines]. Sorry for the negative reply, Hen On Fri, 1 Nov 2002, Travis McCauley wrote: Hello, I apologize if this has been covered recently. I'm trying to find out how to use EL expressions in the 'with' attribute of a str:replace tag. I'm using the 10/8/02 1.0 Release Version. Thanks, Travis -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: EL in String Taglib 1.0
-Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Friday, November 01, 2002 11:21 AM On Fri, 1 Nov 2002, Karr, David wrote: If there's interest in EL-izing certain non-ELed tag libraries, without changing the library (so the original library can still work in Servlet 2.2 environments), and you don't want to wait for JSP 2.0, you might consider using the strategy I used in building the Struts-EL tag library. I was thinking of a strategy that basically did a: Is this class [ExpressionEvaluator or whatever it is] in the classpath. If so, then cache this result statically [in my StringTagSupport] and make sure that ELizing happens. Any reason this would fail? String taglib has a pretty simple design, there's only one actual taglib class, all the rest just do String transformations and not tag stuff, so it can be nice and easy to upgrade :) You're intending to store the class name as a string somewhere, determine whether you can load it, and then call the methods of the class through Reflection? I suppose that would work. You'll have to rip out that code when you move to JSP 2.0. If you used a subclass, you would just remove the subclass. -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: EL in String Taglib 1.0
On Fri, 1 Nov 2002, Karr, David wrote: -Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Friday, November 01, 2002 11:21 AM On Fri, 1 Nov 2002, Karr, David wrote: If there's interest in EL-izing certain non-ELed tag libraries, without changing the library (so the original library can still work in Servlet 2.2 environments), and you don't want to wait for JSP 2.0, you might consider using the strategy I used in building the Struts-EL tag library. I was thinking of a strategy that basically did a: Is this class [ExpressionEvaluator or whatever it is] in the classpath. If so, then cache this result statically [in my StringTagSupport] and make sure that ELizing happens. Any reason this would fail? String taglib has a pretty simple design, there's only one actual taglib class, all the rest just do String transformations and not tag stuff, so it can be nice and easy to upgrade :) You're intending to store the class name as a string somewhere, determine whether you can load it, and then call the methods of the class through Reflection? I suppose that would work. You'll have to rip out that code when you move to JSP 2.0. If you used a subclass, you would just remove the subclass. Kinda. Will play with it a while, see if it'll work. Hen -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: EL in String Taglib 1.0
My goal is to not change the existing library at all, either at the source level or the deployment level. If you put the new classes in the old jar, then people deploying the old taglib will get those extra classes. Those shouldn't cause any conflicts, but I don't like to introduce changes that very likely won't have any effect. -Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Friday, November 01, 2002 12:31 PM On Fri, 1 Nov 2002, Karr, David wrote: All the tag classes in the Struts-EL tag library are subclasses of the corresponding class in the Struts tag library, and all of them look almost identical. In each one, the doStartTag() method calls a method called evaluateExpressions(), which just has one block of almost identical code for each property of the tag, which just passes the current value of the property through the EL parser and into the setter method for the property. The only exception to this relatively Okay. I'm convinced :) Will work on getting a 1.1 release out which has an EL'd component. Any reason it has to be a different jar? Or just one jar with them all and a different tld? -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: EL in String Taglib 1.0
There is that, but in terms of project management for the Jakarta Taglibs, it'll turn each ELized version into a new project, or a branch or somewhat. Unless we declare org.apache.taglibs.name.el to be special perhaps, and output two jars, one with and one without the el sub-package. Will ask Glenn. Hen On Fri, 1 Nov 2002, Karr, David wrote: My goal is to not change the existing library at all, either at the source level or the deployment level. If you put the new classes in the old jar, then people deploying the old taglib will get those extra classes. Those shouldn't cause any conflicts, but I don't like to introduce changes that very likely won't have any effect. -Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Friday, November 01, 2002 12:31 PM On Fri, 1 Nov 2002, Karr, David wrote: All the tag classes in the Struts-EL tag library are subclasses of the corresponding class in the Struts tag library, and all of them look almost identical. In each one, the doStartTag() method calls a method called evaluateExpressions(), which just has one block of almost identical code for each property of the tag, which just passes the current value of the property through the EL parser and into the setter method for the property. The only exception to this relatively Okay. I'm convinced :) Will work on getting a 1.1 release out which has an EL'd component. Any reason it has to be a different jar? Or just one jar with them all and a different tld? -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: EL in String Taglib 1.0
I would recommend creating the EL enabled version as a 2.0 release. Enabling EL in an older non EL taglib can allow you to restructure how your tags work. Some tags or tag attributes may no longer be necessary when the EL is available. Plus doesn't the EL require JSP 1.2? And the current taglib is compatible with JSP 1.1? Adding the EL is enough of a change to warrant a 2.0 release IMHO. Perhaps not from the developer viewpoint, but definitely from the user viewpoint. Regards, Glenn Henri Yandell wrote: There is that, but in terms of project management for the Jakarta Taglibs, it'll turn each ELized version into a new project, or a branch or somewhat. Unless we declare org.apache.taglibs.name.el to be special perhaps, and output two jars, one with and one without the el sub-package. Will ask Glenn. Hen On Fri, 1 Nov 2002, Karr, David wrote: My goal is to not change the existing library at all, either at the source level or the deployment level. If you put the new classes in the old jar, then people deploying the old taglib will get those extra classes. Those shouldn't cause any conflicts, but I don't like to introduce changes that very likely won't have any effect. -Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Friday, November 01, 2002 12:31 PM On Fri, 1 Nov 2002, Karr, David wrote: All the tag classes in the Struts-EL tag library are subclasses of the corresponding class in the Struts tag library, and all of them look almost identical. In each one, the doStartTag() method calls a method called evaluateExpressions(), which just has one block of almost identical code for each property of the tag, which just passes the current value of the property through the EL parser and into the setter method for the property. The only exception to this relatively Okay. I'm convinced :) Will work on getting a 1.1 release out which has an EL'd component. Any reason it has to be a different jar? Or just one jar with them all and a different tld? -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: EL in String Taglib 1.0
-Original Message- From: Glenn Nielsen [mailto:glenn;mail.more.net] Sent: Friday, November 01, 2002 1:02 PM I would recommend creating the EL enabled version as a 2.0 release. Enabling EL in an older non EL taglib can allow you to restructure how your tags work. Some tags or tag attributes may no longer be necessary when the EL is available. Plus doesn't the EL require JSP 1.2? And the current taglib is compatible with JSP 1.1? Adding the EL is enough of a change to warrant a 2.0 release IMHO. Perhaps not from the developer viewpoint, but definitely from the user viewpoint. Why exactly would enabling EL allow you to restructure how your tags work? When you say that some tags or attributes may no longer be necessary, do you mean because some JSTL tag might perform that functionality? In the case of the Struts-EL library, I simply chose not to port certain tags from Struts to Struts-EL if their functionality was entirely provided by a JSTL tag. It didn't allow me restructure how tags work. Yes, using the EL requires JSP 1.2. That's why it's good at this point to keep the -rt and -el versions of libraries somewhat separated. I consider the functionality of a tag library, and the mechanism it uses to evaluate tag attributes, to be independent. Adding an EL-ized version of a library doesn't imply any change to the base library. Users using the -rt library would never notice a difference. However, the people who want to quickly move forward on using and experimenting with the JSTL would have another tool they could more easily integrate with, without having to wait for a 2.0 release. Note that I haven't used the String tag library, nor am I familiar with its contents (although I believe you have some substring matching tags, which is good). I'm just looking to promote usage of the JSTL, which will be more likely if popular tag libraries that do things the JSTL doesn't do can use the same attribute syntax. -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
