Re: Status of Struts-EL contrib project
On 22 Jul 2002, David M. Karr wrote: Date: 22 Jul 2002 09:19:10 -0700 From: David M. Karr [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Status of Struts-EL contrib project I had talked last week about building a tag library, composed of tags derived from the Struts tags, but which use the JSTL expression evaluation engine for attribute values, instead of using JSP rtexprvalues. I thought I would give you a little status on how I'm doing with this. I've finished the bean and logic libraries, and am now working on the html library. Cool! It's occurred to me that if I'm building a tag library that would be used alongside the JSTL, there's not much point in porting Struts tags that duplicate JSTL tag functionality. Therefore, most of the tags in the logic library aren't in my derived library. Part of the library documentation will cover this issue, and will detail exactly which Struts tags were not ported, and which JSTL tags cover their functionality. I would imagine that this (overlap) is also true for some of the tags in the bean library? For example, we probably don't need bean:define ported when c:set does the same sort of thing. While building this, I decided to look at building unit tests for these tags. I thought this would be easy, as I could mutate the unit tests inside the Struts distribution. I was a little surprised to discover that there are actually very few unit tests for the Struts tags, just for logic:equal, logic:notequal, logic:present, and logic:notpresent. I know :-(. So, as another minor subproject to this, I'm experimenting with what I can do to build more complete unit tests for the Struts-EL tags. Almost all of what I'm doing here could be ported back eventually to the Struts unit tests. In particular, for the tags which generate HTML, I'm writing tests (and reusable support code) which verifies the generated output, including checking the attributes and their values which are present or not present in the output. This code uses JUnit, Cactus, and HTTPUnit, along with requiring JTidy, AspectJ, and Xalan. Except for Xalan, these all normally go along with HTTPUnit. That prereq list seems to match what Cactus already requires, right? If so, that should mean nothing extra for me to set up ... I'm also going to look at slightly extending the XML files which describe the tag libraries, to include an element which indicates whether an attribute uses the EL engine for evaluation. This won't be used for generating the tag libraries, only for documentation generation. That would be super, and is one of the reasons I chose to generate the TLDs from a separate XML file that could contain additional information. I'll provide more information as I get closer to completion (or what looks like completion to me). Any comments or questions? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Status of Struts-EL contrib project
On 22 Jul 2002, David M. Karr wrote: Date: 22 Jul 2002 09:53:58 -0700 From: David M. Karr [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Status of Struts-EL contrib project Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 22 Jul 2002, David M. Karr wrote: It's occurred to me that if I'm building a tag library that would be used alongside the JSTL, there's not much point in porting Struts tags that duplicate JSTL tag functionality. Therefore, most of the tags in the logic library aren't in my derived library. Part of the library documentation will cover this issue, and will detail exactly which Struts tags were not ported, and which JSTL tags cover their functionality. Craig I would imagine that this (overlap) is also true for some of the tags in Craig the bean library? For example, we probably don't need bean:define Craig ported when c:set does the same sort of thing. Yes. The logic tags were just an example. I know at least bean:define wasn't needed, but I don't remember offhand if any others from bean weren't needed. ok. So, as another minor subproject to this, I'm experimenting with what I can do to build more complete unit tests for the Struts-EL tags. Almost all of what I'm doing here could be ported back eventually to the Struts unit tests. In particular, for the tags which generate HTML, I'm writing tests (and reusable support code) which verifies the generated output, including checking the attributes and their values which are present or not present in the output. This code uses JUnit, Cactus, and HTTPUnit, along with requiring JTidy, AspectJ, and Xalan. Except for Xalan, these all normally go along with HTTPUnit. Craig That prereq list seems to match what Cactus already requires, right? If Craig so, that should mean nothing extra for me to set up ... Well, Cactus doesn't necessarily require HTTPUnit, JTidy, or AspectJ, only if you use the features of Cactus that need those other libraries. I don't believe the existing Struts test cases required any of those. That's true, to my recollection. In any case, just making them available and pointing to them from the build.properties will suffice. I don't believe Xalan is required for Cactus, however. That's just used by my code which gets and validates the attributes. Xalan is needed to produce the Struts documentation and TLDs anyway, so that shouldn't be a problem -- as long as you only need it at compile and test time. Are you contemplating a runtime dependency on Xalan as well? Craig -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- 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]
Re: Status of Struts-EL contrib project
Subject: Re: Status of Struts-EL contrib project From: Vic C. [EMAIL PROTECTED] === It appears that only HTML tag would need conversion. ? I would think that logic and bean tag would be deprecated over time since there is JSTL equivalents as Craig mentioned before, if I recall. Also, I have posted an example on sourceforge (basicPortal) of an JSTL for each tag with struts HTML for multi row update(it has a minor bug now - approve content page), should that be of use. I will continue to write realistic sample of using Struts with JSTL so should you need web app sample I will be incorporating what ever you post ASAP. Where would you post it? Vic David M. Karr wrote: Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 22 Jul 2002, David M. Karr wrote: It's occurred to me that if I'm building a tag library that would be used alongside the JSTL, there's not much point in porting Struts tags that duplicate JSTL tag functionality. Therefore, most of the tags in the logic library aren't in my derived library. Part of the library documentation will cover this issue, and will detail exactly which Struts tags were not ported, and which JSTL tags cover their functionality. Craig I would imagine that this (overlap) is also true for some of the tags in Craig the bean library? For example, we probably don't need bean:define Craig ported when c:set does the same sort of thing. Yes. The logic tags were just an example. I know at least bean:define wasn't needed, but I don't remember offhand if any others from bean weren't needed. So, as another minor subproject to this, I'm experimenting with what I can do to build more complete unit tests for the Struts-EL tags. Almost all of what I'm doing here could be ported back eventually to the Struts unit tests. In particular, for the tags which generate HTML, I'm writing tests (and reusable support code) which verifies the generated output, including checking the attributes and their values which are present or not present in the output. This code uses JUnit, Cactus, and HTTPUnit, along with requiring JTidy, AspectJ, and Xalan. Except for Xalan, these all normally go along with HTTPUnit. Craig That prereq list seems to match what Cactus already requires, right? If Craig so, that should mean nothing extra for me to set up ... Well, Cactus doesn't necessarily require HTTPUnit, JTidy, or AspectJ, only if you use the features of Cactus that need those other libraries. I don't believe the existing Struts test cases required any of those. In any case, just making them available and pointing to them from the build.properties will suffice. I don't believe Xalan is required for Cactus, however. That's just used by my code which gets and validates the attributes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Status of Struts-EL contrib project
On Mon, 22 Jul 2002, Struts-dev Newsgroup wrote: Date: Mon, 22 Jul 2002 10:25:01 -0700 From: Struts-dev Newsgroup [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Status of Struts-EL contrib project Subject: Re: Status of Struts-EL contrib project From: Vic C. [EMAIL PROTECTED] === It appears that only HTML tag would need conversion. ? I would think that logic and bean tag would be deprecated over time since there is JSTL equivalents as Craig mentioned before, if I recall. That kind of deprecation wwould happen in some future rev of Struts. For 1.1, we still require only Servlet 2.2 / JSP 1.1 as prerequisites, and the library that David is working won't be added to the core of 1.1, since JSTL requires Servlet 2.3 / JSP 1.2. I suspect the same sort of thing will happen (ultimate deprecation but continued support) for most of the html tag library, once JavaServer Faces becomes available. Also, I have posted an example on sourceforge (basicPortal) of an JSTL for each tag with struts HTML for multi row update(it has a minor bug now - approve content page), should that be of use. I will continue to write realistic sample of using Struts with JSTL so should you need web app sample I will be incorporating what ever you post ASAP. Where would you post it? Better multi-row support in general, and master-detail in particular, are two areas on my wish list for direct support by Struts in a post-1.1 release. Whether we end up building them on top of JSTL and Faces tags, or implement them separately, will be an interesting design decision. In the mean time, having realistic examples is very useful for people who need this kind of thing now instead of later, as well as to validate the functional requirements. Vic Craig David M. Karr wrote: Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 22 Jul 2002, David M. Karr wrote: It's occurred to me that if I'm building a tag library that would be used alongside the JSTL, there's not much point in porting Struts tags that duplicate JSTL tag functionality. Therefore, most of the tags in the logic library aren't in my derived library. Part of the library documentation will cover this issue, and will detail exactly which Struts tags were not ported, and which JSTL tags cover their functionality. Craig I would imagine that this (overlap) is also true for some of the tags in Craig the bean library? For example, we probably don't need bean:define Craig ported when c:set does the same sort of thing. Yes. The logic tags were just an example. I know at least bean:define wasn't needed, but I don't remember offhand if any others from bean weren't needed. So, as another minor subproject to this, I'm experimenting with what I can do to build more complete unit tests for the Struts-EL tags. Almost all of what I'm doing here could be ported back eventually to the Struts unit tests. In particular, for the tags which generate HTML, I'm writing tests (and reusable support code) which verifies the generated output, including checking the attributes and their values which are present or not present in the output. This code uses JUnit, Cactus, and HTTPUnit, along with requiring JTidy, AspectJ, and Xalan. Except for Xalan, these all normally go along with HTTPUnit. Craig That prereq list seems to match what Cactus already requires, right? If Craig so, that should mean nothing extra for me to set up ... Well, Cactus doesn't necessarily require HTTPUnit, JTidy, or AspectJ, only if you use the features of Cactus that need those other libraries. I don't believe the existing Struts test cases required any of those. In any case, just making them available and pointing to them from the build.properties will suffice. I don't believe Xalan is required for Cactus, however. That's just used by my code which gets and validates the attributes. -- 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]
Re: Status of Struts-EL contrib project
Struts-dev == Struts-dev Newsgroup (@Basebeans.com) [EMAIL PROTECTED] writes: Struts-dev Subject: Re: Status of Struts-EL contrib project Struts-dev From: Vic C. [EMAIL PROTECTED] Struts-dev === Struts-dev It appears that only HTML tag would need conversion. ? Struts-dev I would think that logic and bean tag would be deprecated over time Struts-dev since there is JSTL equivalents as Craig mentioned before, if I recall. There are still some tags in the logic and bean libraries that don't have JSTL equivalents. Struts-dev Also, I have posted an example on sourceforge (basicPortal) of an JSTL Struts-dev for each tag with struts HTML for multi row update(it has a minor bug Struts-dev now - approve content page), should that be of use. I will continue to Struts-dev write realistic sample of using Struts with JSTL so should you need Struts-dev web app sample I will be incorporating what ever you post ASAP. Struts-dev Where would you post it? I'll take a look at at your code when I get a chance. Thanks for the pointer. You'll hear about it on struts-dev. Hopefully, it will be integrated into Struts as a contrib project. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Status of Struts-EL contrib project - tangent
Subject: Re: Status of Struts-EL contrib project - tangent From: Vic C. [EMAIL PROTECTED] === Craig R. McClanahan wrote: Better multi-row support in general, and master-detail in particular, are two areas on my wish list for direct support by Struts in a post-1.1 release. Adding iterator to formBean for multi-row and a formBean that contains a formBean (for master-detail) is one approach I used in production at 2 clients (and a few variations). My favorite part is that one can unit test master-detail CRUD from a console app. before Struts. V. Craig R. McClanahan wrote: On Mon, 22 Jul 2002, Struts-dev Newsgroup wrote: Date: Mon, 22 Jul 2002 10:25:01 -0700 From: Struts-dev Newsgroup [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Status of Struts-EL contrib project Subject: Re: Status of Struts-EL contrib project From: Vic C. [EMAIL PROTECTED] === It appears that only HTML tag would need conversion. ? I would think that logic and bean tag would be deprecated over time since there is JSTL equivalents as Craig mentioned before, if I recall. That kind of deprecation wwould happen in some future rev of Struts. For 1.1, we still require only Servlet 2.2 / JSP 1.1 as prerequisites, and the library that David is working won't be added to the core of 1.1, since JSTL requires Servlet 2.3 / JSP 1.2. I suspect the same sort of thing will happen (ultimate deprecation but continued support) for most of the html tag library, once JavaServer Faces becomes available. Also, I have posted an example on sourceforge (basicPortal) of an JSTL for each tag with struts HTML for multi row update(it has a minor bug now - approve content page), should that be of use. I will continue to write realistic sample of using Struts with JSTL so should you need web app sample I will be incorporating what ever you post ASAP. Where would you post it? Better multi-row support in general, and master-detail in particular, are two areas on my wish list for direct support by Struts in a post-1.1 release. Whether we end up building them on top of JSTL and Faces tags, or implement them separately, will be an interesting design decision. In the mean time, having realistic examples is very useful for people who need this kind of thing now instead of later, as well as to validate the functional requirements. Vic Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Status of Struts-EL contrib project
David, From your original post I assumed you were going to provide JSTL style struts tags by incorporating the EL functionality of JTSL (I read somewhere it was going to be split out from the JSTL, perhaps to commons) with the main aim being that struts developers could use them now (with Servlet 2.2 / JSP 1.1) and making the migration to JSTL much easier. From what you say below it seems the intention is to move the struts tags which provide functionality that JSTL doesn't have to work in a compatible way with JSTL. Can you clarify this and are you just using the EL of JSTL or will your ammendments need the whole of JSTL and require Servlet 2.3 / JSP 1.2? Niall -Original Message- From: David M. Karr [mailto:[EMAIL PROTECTED]] Sent: 22 July 2002 17:19 To: [EMAIL PROTECTED] Subject: Status of Struts-EL contrib project I had talked last week about building a tag library, composed of tags derived from the Struts tags, but which use the JSTL expression evaluation engine for attribute values, instead of using JSP rtexprvalues. I thought I would give you a little status on how I'm doing with this. I've finished the bean and logic libraries, and am now working on the html library. It's occurred to me that if I'm building a tag library that would be used alongside the JSTL, there's not much point in porting Struts tags that duplicate JSTL tag functionality. Therefore, most of the tags in the logic library aren't in my derived library. Part of the library documentation will cover this issue, and will detail exactly which Struts tags were not ported, and which JSTL tags cover their functionality. While building this, I decided to look at building unit tests for these tags. I thought this would be easy, as I could mutate the unit tests inside the Struts distribution. I was a little surprised to discover that there are actually very few unit tests for the Struts tags, just for logic:equal, logic:notequal, logic:present, and logic:notpresent. So, as another minor subproject to this, I'm experimenting with what I can do to build more complete unit tests for the Struts-EL tags. Almost all of what I'm doing here could be ported back eventually to the Struts unit tests. In particular, for the tags which generate HTML, I'm writing tests (and reusable support code) which verifies the generated output, including checking the attributes and their values which are present or not present in the output. This code uses JUnit, Cactus, and HTTPUnit, along with requiring JTidy, AspectJ, and Xalan. Except for Xalan, these all normally go along with HTTPUnit. I'm also going to look at slightly extending the XML files which describe the tag libraries, to include an element which indicates whether an attribute uses the EL engine for evaluation. This won't be used for generating the tag libraries, only for documentation generation. I'll provide more information as I get closer to completion (or what looks like completion to me). Any comments or questions? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- 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]
Re: Status of Struts-EL contrib project
Niall == Niall Pemberton [EMAIL PROTECTED] writes: Niall David, From your original post I assumed you were going to provide JSTL style Niall struts tags by incorporating the EL functionality of JTSL (I read Niall somewhere it was going to be split out from the JSTL, perhaps to commons) Niall with the main aim being that struts developers could use them now (with Niall Servlet 2.2 / JSP 1.1) and making the migration to JSTL much easier. From what you say below it seems the intention is to move the struts tags Niall which provide functionality that JSTL doesn't have to work in a compatible Niall way with JSTL. Niall Can you clarify this and are you just using the EL of JSTL or will your Niall ammendments need the whole of JSTL and require Servlet 2.3 / JSP 1.2? Hmm, I was not aiming for a Servlet 2.2 solution, but it's possible that could happen. As you suggested, I'm only implementing the Struts tags which provide functionality not in the JSTL. I'm implementing them by using the internal EL engine from the JSTL. If we were to try to get it work with Servlet 2.2, you would essentially have to use both sets of Struts tag libraries (and not use the JSTL tags at all). You would use this library to get the JSTL functionality, and the regular library to get the functionality I'm not porting. I believe that can work, although I'm not directly testing for that. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Status of Struts-EL contrib project
On Tue, 23 Jul 2002, Niall Pemberton wrote: Date: Tue, 23 Jul 2002 03:28:22 +0100 From: Niall Pemberton [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Status of Struts-EL contrib project David, From your original post I assumed you were going to provide JSTL style struts tags by incorporating the EL functionality of JTSL (I read somewhere it was going to be split out from the JSTL, perhaps to commons) with the main aim being that struts developers could use them now (with Servlet 2.2 / JSP 1.1) and making the migration to JSTL much easier. From what you say below it seems the intention is to move the struts tags which provide functionality that JSTL doesn't have to work in a compatible way with JSTL. Can you clarify this and are you just using the EL of JSTL or will your ammendments need the whole of JSTL and require Servlet 2.3 / JSP 1.2? My understanding of what David is proposing is that he's creating variants of the existing Struts tags, which define attributes that accept JSTL-like EL expressions rather than the name/property/scope triple that is the usual Struts approach. Further, the plan is to leverage the expression language interpreter in the JSTL reference implementation (which is basically the standard taglib from jakarta-taglibs). It would presumably be possible to extract just the EL interpreter out of the standard taglib (in fact, this is likely to become a jakarta-commons package on its own anyway). But it seems to me that this is primarily targeted for people who want to use JSTL tags in conjunction with Struts tags -- and, because JSTL requires Servlet 2.3 / JSP 1.2, so would the use of this tag library extension. Given the number of Servlet 2.3 / JSP 1.2 containers in the world already (including every J2EE 1.3 container), it doesn't seem worth any extra effort to support this EL stuff on Servlet 2.2 / JSP 1.1 (unless it is trivially simple). And even then, it seems less than useful since you won't be able to use JSTL tags anyway (so you will miss all the Struts tags that aren't being ported). I look at this primarily as an extension library that will work just fine with Struts, but only on Servlet 2.3 / JSP 1.2 containers. David, of course, might have different things in mind. Niall Craig -Original Message- From: David M. Karr [mailto:[EMAIL PROTECTED]] Sent: 22 July 2002 17:19 To: [EMAIL PROTECTED] Subject: Status of Struts-EL contrib project I had talked last week about building a tag library, composed of tags derived from the Struts tags, but which use the JSTL expression evaluation engine for attribute values, instead of using JSP rtexprvalues. I thought I would give you a little status on how I'm doing with this. I've finished the bean and logic libraries, and am now working on the html library. It's occurred to me that if I'm building a tag library that would be used alongside the JSTL, there's not much point in porting Struts tags that duplicate JSTL tag functionality. Therefore, most of the tags in the logic library aren't in my derived library. Part of the library documentation will cover this issue, and will detail exactly which Struts tags were not ported, and which JSTL tags cover their functionality. While building this, I decided to look at building unit tests for these tags. I thought this would be easy, as I could mutate the unit tests inside the Struts distribution. I was a little surprised to discover that there are actually very few unit tests for the Struts tags, just for logic:equal, logic:notequal, logic:present, and logic:notpresent. So, as another minor subproject to this, I'm experimenting with what I can do to build more complete unit tests for the Struts-EL tags. Almost all of what I'm doing here could be ported back eventually to the Struts unit tests. In particular, for the tags which generate HTML, I'm writing tests (and reusable support code) which verifies the generated output, including checking the attributes and their values which are present or not present in the output. This code uses JUnit, Cactus, and HTTPUnit, along with requiring JTidy, AspectJ, and Xalan. Except for Xalan, these all normally go along with HTTPUnit. I'm also going to look at slightly extending the XML files which describe the tag libraries, to include an element which indicates whether an attribute uses the EL engine for evaluation. This won't be used for generating the tag libraries, only for documentation generation. I'll provide more information as I get closer to completion (or what looks like completion to me). Any comments or questions? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail
