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]
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]
DO NOT REPLY [Bug 11050] New: - No way to properly validate form properties of types other than String
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11050. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11050 No way to properly validate form properties of types other than String Summary: No way to properly validate form properties of types other than String Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm not sure if it was supposed to be that way, but currently validating form properties other than of String types does not work as expected. Suppose we have a form with Integer field. If user does not enter anything in this field and submits, then this field will get a default values of 0 because this is default behaviour of IntegerConverter class. So this field will pass requried validation, and will get value of zero wothout user knowing anything, which is completely wrong! The same issue will arise if user enters invalid integer. Instead of error message saying that this is not a valid integer, a default zero value will be silentely submitted. Even if we change IntegerConverter's behaviour to return null instead of zero for invalid Integers, we still don't get expected from validation logic! Although, requried works, checking for valid integer value does not even gets in place, because requried fails after IntegerConvertes returns null since it cannot parse invalid Integer value. This issue is easy to reproduce - just change form field type from String to Integer in struts-validation sample app. Is there a good workaround anyone can suggest? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11051] New: - Turning off definitions validation still causes failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11051. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11051 Turning off definitions validation still causes failure Summary: Turning off definitions validation still causes failure Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Tiles framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I thought I could turn-off tile's definitions validation by changing 'definitions-parser-validate' to false in my web.xml - but I still get the error below. Here is my web.xml entry: !-- Action Servlet Configuration -- servlet servlet-nameaction/servlet-name servlet-classorg.apache.struts.tiles.ActionComponentServlet/servlet- class init-param param-namedefinitions-config/param-name param-value/WEB-INF/tiles-config.xml, /WEB-INF/tiles-config-viewer.xml, /WEB-INF/tiles-config-menu.xml /param-value /init-param init-param param-namedefinitions-debug/param-name param-value0/param-value /init-param init-param param-namedefinitions-parser-details/param-name param-value0/param-value /init-param init-param param-namedefinitions-parser-validate/param-name param-valuefalse/param-value /init-param init-param param-nameconfig/param-name param-value/WEB-INF/struts-config.xml/param-value /init-param init-param param-namedebug/param-name param-value2/param-value /init-param init-param param-namedetail/param-name param-value2/param-value /init-param init-param param-namenocache/param-name param-valuetrue/param-value /init-param init-param param-namevalidate/param-name param-valuetrue/param-value /init-param load-on-startup3/load-on-startup /servlet Here is the error I get: ERROR [main] [org.apache.commons.digester.Digester] Digester.fatalError(1193) | Parse Fatal Error at line 2 xternal entity not found: http://jakarta.apache.org/struts/dtds/tiles- config.dtd. java.net.UnknownHostException: jakarta.apache.org at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3182) at org.apache.crimson.parser.Parser2.externalParameterEntity (Parser2.java:2870) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl (Parser2.java:1167) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:489) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11050] - No way to properly validate form properties of types other than String
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11050. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11050 No way to properly validate form properties of types other than String [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-07-22 18:56 --- The best, and recognised, practice is to using Strings for all of your form bean properties. Apart from the problems you are seeing, using an Integer also results in incorrect feedback being given to the user when validation fails. If the user typed abc into a field that was supposed to be numeric, using an Integer property would result in 0 being displayed, along with a message saying that the value they entered was not numeric. Clearly, what you want is to redisplay the original, invalid, value they entered, instead of 0. To do that, you need to use a String property. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11050] - No way to properly validate form properties of types other than String
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11050.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11050
No way to properly validate form properties of types other than String
--- Additional Comments From [EMAIL PROTECTED] 2002-07-22 20:39 ---
I understand what you are saying. My main intention was to reuse existing data
beans as a nested properties of the form bean.
For example, consider a User bean with name, password and age properties.
Age is numeric property. Now I can define a form bean, which will contain user
property of type User. I can even easily define form as dynamic with dynamic
user property:
form-bean name=createUserForm
type=org.apache.struts.validator.DynaValidatorForm dynamic=true
form-property name=user type=User/
/form-bean
Now I can have the following in my JSP pages:
...
html:form action=/createuser
nested:nest property=user
table
tr
thbean:message key=user.name//th
tdnested:text property=name//td
/tr
tr
thbean:message key=user.password//th
tdnested:password property=password redisplay=false//td
/tr
tr
thbean:message key=user.age//th
tdnested:text property=age//td
/tr
/table
/nested:nest
/html:form
... and validation rules:
form-validation
formset
form name=createUserForm
field property=user.name
depends=required
arg0 key=user.name/
/field
field property=user.password
depends=required, minlength
arg0 key=user.password/
arg1 name=minlength key=${var:minlength} resource=false/
var
var-nameminlength/var-name
var-value5/var-value
/var
/field
field property=user.age
depends=required, integer
arg0 key=user.age/
/field
form name=createUserForm
formset
form-validation
...
Everything works fine except age validation, like I described before.
One of the reasons of resusing existing bean is that I can copy it back and
forth between the form and buisness logic objects using
PropertyUtils.copyProperties() or similar methods:
public class CreateUserAction extends Action
{
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException, WorkitemException
{
CreateUserCommand = new CreateUserCommand(); // business logic
if (form != null)
ActionHelpier.copyProperties(command, form);
comand.execute();
...
}
I could have used Strings for form bean properties, but struts tags will fail to
resolve nested properties. For example, I could have defined my form bean as
follows:
form-bean name=createUserForm
type=org.apache.struts.validator.DynaValidatorForm dynamic=true
form-property name=user.name type=java.lang.String/
form-property name=user.password type=java.lang.String/
form-property name=user.age type=java.lang.String/
/form-bean
Form properties would be converted from String into native User bean property
types, but I can't make struts tag libraries work with nested forms properties
defined as above...
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11050] - No way to properly validate form properties of types other than String
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11050. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11050 No way to properly validate form properties of types other than String [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-07-22 20:40 --- I'm reopening this bug just to draw other's attention to my previous comments :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10501] - Error running struts under JRun 3.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10501.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10501
Error running struts under JRun 3.1
--- Additional Comments From [EMAIL PROTECTED] 2002-07-23 00:12 ---
I've run into a problem similar to this before. I found that JRun3.1 was not
setting the web-inf classloader through Thread.setContextClassLoader() when
loading the servlet on startup. If this is not set, then i believe the logger
will try to load its classes through the primordial classloader, but this is
not where the commons-logging.jar is located, so you get a
ClassNotFoundException. I've pointed this problem out to the JRun support
people, there suggestion was to switch to JRun 4 which supports the Servlet 2.3
spec. I've tried out struts1.1 beta1 with JRun 4 and it all works fine. If you
are stuck with JRun3.1, it looks like you may be stuck with Struts1.0...or you
can modify ActionServlet to set the ContextLoader in its init method before
initialization of its logging classes.
Of course this hack does not belong in Struts. But since you can't get to the
JRun source code...
init(ServletConfig sc)
{
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
..
//INIT logging here
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
NPE when setting values on DynaActionForm
I want to populate a DynaActionForm before dispatching to a JSP, however the following doesn't work: DynaActionForm requestForm = new DynaActionForm(); requestForm.set(subject, subject); requestForm.set(content, content); requestForm.set(courseId, cForm.getCourseId()); requestForm.set(courseName, cForm.getName()); I get a NPE at the first .set - here is my configuration: form-bean name=requestForm type=org.apache.struts.action.DynaActionForm form-property name=action type=java.lang.String/ form-property name=courseId type=java.lang.String/ form-property name=courseName type=java.lang.String/ form-property name=type type=java.lang.String/ form-property name=subject type=java.lang.String/ form-property name=content type=java.lang.String/ form-property name=message type=java.lang.String/ /form-bean Should it? Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NPE when setting values on DynaActionForm
A stack track may help: Caused by: java.lang.NullPointerException at org.apache.struts.action.DynaActionForm.getDynaProperty(DynaActionForm.java:539) at org.apache.struts.action.DynaActionForm.set(DynaActionForm.java:357) at com.onpoint.webapp.action.CourseCatalogAction.add(CourseCatalogAction.java:86) ... 47 more Line 86 is the first set below --- Matt Raible [EMAIL PROTECTED] wrote: I want to populate a DynaActionForm before dispatching to a JSP, however the following doesn't work: DynaActionForm requestForm = new DynaActionForm(); requestForm.set(subject, subject); requestForm.set(content, content); requestForm.set(courseId, cForm.getCourseId()); requestForm.set(courseName, cForm.getName()); I get a NPE at the first .set - here is my configuration: form-bean name=requestForm type=org.apache.struts.action.DynaActionForm form-property name=action type=java.lang.String/ form-property name=courseId type=java.lang.String/ form-property name=courseName type=java.lang.String/ form-property name=type type=java.lang.String/ form-property name=subject type=java.lang.String/ form-property name=content type=java.lang.String/ form-property name=message type=java.lang.String/ /form-bean Should it? Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NPE when setting values on DynaActionForm
On Mon, 22 Jul 2002, Matt Raible wrote: Date: Mon, 22 Jul 2002 18:40:56 -0600 From: Matt Raible [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: NPE when setting values on DynaActionForm I want to populate a DynaActionForm before dispatching to a JSP, however the following doesn't work: DynaActionForm requestForm = new DynaActionForm(); requestForm.set(subject, subject); requestForm.set(content, content); requestForm.set(courseId, cForm.getCourseId()); requestForm.set(courseName, cForm.getName()); I get a NPE at the first .set - here is my configuration: This won't work because the DynaActionForm you created doesn't know what the set of valid properties are. form-bean name=requestForm type=org.apache.struts.action.DynaActionForm form-property name=action type=java.lang.String/ form-property name=courseId type=java.lang.String/ form-property name=courseName type=java.lang.String/ form-property name=type type=java.lang.String/ form-property name=subject type=java.lang.String/ form-property name=content type=java.lang.String/ form-property name=message type=java.lang.String/ /form-bean Should it? With the current APIs, it is surprisingly hard to do this, because there is no convenient way to get to the underlying DynaActionFormClass instance. Im going to be adding some API in tonight's nightly build so that you will be able to say: DynaActionForm requestForm = DynaActionFormClass.getDynaClass(requestForm).newInstance(); to get a DynaActionForm initalized with the correct properties. In the mean time, a workaround is to declare that your setup action also uses this form bean (so that Struts will set it up for you), or go through the following exercise: ApplicationConfig appConfig = (ApplicationConfig) request.getAttribute(Action.APPLICATION_KEY); FormBeanConfig fbConfig = appConfig.findFormBeanConfig(requestForm); DynaActionForm requestForm = DynaActionFormClass.createDynaActionFormClass(fbConfig).newInstance(); Thanks, Matt Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NPE when setting values on DynaActionForm
--- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 22 Jul 2002, Matt Raible wrote: Date: Mon, 22 Jul 2002 18:40:56 -0600 From: Matt Raible [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: NPE when setting values on DynaActionForm I want to populate a DynaActionForm before dispatching to a JSP, however the following doesn't work: DynaActionForm requestForm = new DynaActionForm(); requestForm.set(subject, subject); requestForm.set(content, content); requestForm.set(courseId, cForm.getCourseId()); requestForm.set(courseName, cForm.getName()); I get a NPE at the first .set - here is my configuration: This won't work because the DynaActionForm you created doesn't know what the set of valid properties are. form-bean name=requestForm type=org.apache.struts.action.DynaActionForm form-property name=action type=java.lang.String/ form-property name=courseId type=java.lang.String/ form-property name=courseName type=java.lang.String/ form-property name=type type=java.lang.String/ form-property name=subject type=java.lang.String/ form-property name=content type=java.lang.String/ form-property name=message type=java.lang.String/ /form-bean Should it? With the current APIs, it is surprisingly hard to do this, because there is no convenient way to get to the underlying DynaActionFormClass instance. Im going to be adding some API in tonight's nightly build so that you will be able to say: DynaActionForm requestForm = DynaActionFormClass.getDynaClass(requestForm).newInstance(); I'd much rather do the above ^ than the below. I'll look for a commit that resembles this and download the nightly tomorrow. Will it just be in BeanUtils? I'd be willing to make the jump to 1.1 nightly if Tiles has been safely integrated and there's a plugin example. Last time I updated was a few weeks ago. to get a DynaActionForm initalized with the correct properties. In the mean time, a workaround is to declare that your setup action also uses this form bean (so that Struts will set it up for you), or go through the following exercise: ApplicationConfig appConfig = (ApplicationConfig) request.getAttribute(Action.APPLICATION_KEY); FormBeanConfig fbConfig = appConfig.findFormBeanConfig(requestForm); DynaActionForm requestForm = DynaActionFormClass.createDynaActionFormClass(fbConfig).newInstance(); Thanks, Matt Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Thanks, Matt __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/action DynaActionFormClass.java
craigmcc2002/07/22 18:02:52
Modified:src/share/org/apache/struts/action DynaActionFormClass.java
Log:
Make it possible to retrieve a previously configured DynaActionFormClass
instance with the specified name. TODO: ensure that all possible dynamic
form beans have had this done at startup time, instead of waiting for the
first time a particular dynamic form is requested.
Revision ChangesPath
1.8 +26 -4
jakarta-struts/src/share/org/apache/struts/action/DynaActionFormClass.java
Index: DynaActionFormClass.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/DynaActionFormClass.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- DynaActionFormClass.java 13 Jul 2002 18:05:05 - 1.7
+++ DynaActionFormClass.java 23 Jul 2002 01:02:51 - 1.8
@@ -321,6 +321,28 @@
}
+/**
+ * Return an existing codeDynaActionFormClass/code of the specified
+ * name, if one has been configured previously. If no such instance has
+ * been configured, return codenull/code instead.
+ *
+ * @param name Name of the codeDynaActionFormClass/code to be
+ * returned
+ */
+public static DynaActionFormClass
+getDynaActionFormClass(String name) {
+
+synchronized (lock) {
+if (dynaClasses == null) {
+return (null);
+} else {
+return ((DynaActionFormClass) dynaClasses.get(name));
+}
+}
+
+}
+
+
// -- Protected Methods
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NPE when setting values on DynaActionForm
See below. On Mon, 22 Jul 2002, Matt Raible wrote: Date: Mon, 22 Jul 2002 18:00:29 -0700 (PDT) From: Matt Raible [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: NPE when setting values on DynaActionForm --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 22 Jul 2002, Matt Raible wrote: Date: Mon, 22 Jul 2002 18:40:56 -0600 From: Matt Raible [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: NPE when setting values on DynaActionForm I want to populate a DynaActionForm before dispatching to a JSP, however the following doesn't work: DynaActionForm requestForm = new DynaActionForm(); requestForm.set(subject, subject); requestForm.set(content, content); requestForm.set(courseId, cForm.getCourseId()); requestForm.set(courseName, cForm.getName()); I get a NPE at the first .set - here is my configuration: This won't work because the DynaActionForm you created doesn't know what the set of valid properties are. form-bean name=requestForm type=org.apache.struts.action.DynaActionForm form-property name=action type=java.lang.String/ form-property name=courseId type=java.lang.String/ form-property name=courseName type=java.lang.String/ form-property name=type type=java.lang.String/ form-property name=subject type=java.lang.String/ form-property name=content type=java.lang.String/ form-property name=message type=java.lang.String/ /form-bean Should it? With the current APIs, it is surprisingly hard to do this, because there is no convenient way to get to the underlying DynaActionFormClass instance. Im going to be adding some API in tonight's nightly build so that you will be able to say: DynaActionForm requestForm = DynaActionFormClass.getDynaClass(requestForm).newInstance(); I'd much rather do the above ^ than the below. I don't blame you :-). I'll look for a commit that resembles this and download the nightly tomorrow. Will it just be in BeanUtils? No, the modification is on DynaActionFormClass itself, so its just a Struts thing. I'd be willing to make the jump to 1.1 nightly if Tiles has been safely integrated and there's a plugin example. Last time I updated was a few weeks ago. I believe this was recently addressed. to get a DynaActionForm initalized with the correct properties. In the mean time, a workaround is to declare that your setup action also uses this form bean (so that Struts will set it up for you), or go through the following exercise: ApplicationConfig appConfig = (ApplicationConfig) request.getAttribute(Action.APPLICATION_KEY); FormBeanConfig fbConfig = appConfig.findFormBeanConfig(requestForm); DynaActionForm requestForm = DynaActionFormClass.createDynaActionFormClass(fbConfig).newInstance(); Thanks, Matt Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Thanks, Matt Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java
craigmcc2002/07/22 18:17:02
Modified:src/share/org/apache/struts/action ActionServlet.java
Log:
Ensure that all the configured dynamic form bean classes have been created
at startup time, so that DynaActionFormClass.getDynaActionFormClass() will
always work. As a side effect, this will catch problems with the specified
class name at webapp startup time instead of the first time this form bean
is requested.
Revision ChangesPath
1.115 +13 -4
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
Index: ActionServlet.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
retrieving revision 1.114
retrieving revision 1.115
diff -u -r1.114 -r1.115
--- ActionServlet.java10 Jul 2002 14:52:46 - 1.114
+++ ActionServlet.java23 Jul 2002 01:17:02 - 1.115
@@ -864,6 +864,15 @@
}
}
+// Force creation and registration of DynaActionFormClass instances
+// for all dynamic form beans we wil be using
+FormBeanConfig fbs[] = config.findFormBeanConfigs();
+for (int i = 0; i fbs.length; i++) {
+if (fbs[i].getDynamic()) {
+DynaActionFormClass.createDynaActionFormClass(fbs[i]);
+}
+}
+
// Special handling for the default application module (for
// backwards compatibility only, will be removed later)
if (prefix.length() 1) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NPE when setting values on DynaActionForm
The required changes to implement this has been checked in, and will be available in nightly build 20020723 of Struts. The only difference is that you need to call: DynaActionForm requestForm = DynaActionFormClass.getDynaActionFormClass(requestForm).newInstance(); instead of the previously quoted method name, for consistency with previous method signatures. 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:
Struts-EL: Ideas about name and indexed name attributes?
In mapping Struts tags to Struts-EL, I'm wondering about the name attribute of the generated HTML for these tags, along with the property attribute of the custom tag, and indexed tags. In the current Struts library, in the checkbox tag, for instance, the strategy of setting the name and property attributes nicely flows the specified field values back into the specified actionform and property on the return trip. If the indexed attribute is set, it nicely builds an index reference, which will eventually cause the correct array/collection entry to be set. I'm thinking and thinking about how I can possibly map something like this to JSTL functionality, and I just don't see it. I was assuming that the name/property functionality would be mutually exclusive with the JSTL functionality, but in at least the HTML tags, where the name/property pair is used to build the HTML name attribute, I don't see how I can replace that. In the case of checkbox, the value attribute and others could still use the EL engine, just not the name/property functionality. Does anyone have any ideas about this? -- === 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: Struts-EL: Ideas about name and indexed name attributes?
On 22 Jul 2002, David M. Karr wrote:
Date: 22 Jul 2002 20:07:22 -0700
From: David M. Karr [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Struts-EL: Ideas about name and indexed name attributes?
In mapping Struts tags to Struts-EL, I'm wondering about the name attribute
of the generated HTML for these tags, along with the property attribute of
the custom tag, and indexed tags.
In the current Struts library, in the checkbox tag, for instance, the
strategy of setting the name and property attributes nicely flows the
specified field values back into the specified actionform and property on the
return trip. If the indexed attribute is set, it nicely builds an index
reference, which will eventually cause the correct array/collection entry to be
set.
I'm thinking and thinking about how I can possibly map something like this to
JSTL functionality, and I just don't see it. I was assuming that the
name/property functionality would be mutually exclusive with the JSTL
functionality, but in at least the HTML tags, where the name/property pair is
used to build the HTML name attribute, I don't see how I can replace that.
In the case of checkbox, the value attribute and others could still use the
EL engine, just not the name/property functionality.
Does anyone have any ideas about this?
I've been thinking about this issue as well, as you might imagine.
For general form field properties, I'm assuming that we would have to make
the existence of the form bean explict -- say, for example:
html-el:test var=${logonForm.username}/
instead of assuming that you could just use username and know that it
was resolved against the form bean in the surrounding scope. The property
name can either be inferred from the expression (i.e. after the first
period), or we could allow an optional property attribute that would
provide the field name for the rendered input field.
For indexed things, remember that the subscript in an EL expression can be
a variable. So something like this should work, where customers is an
array of customer objects, and we're inside a form with a field per
customer account number:
c:forEach var=customer items=customers varStatus=status
html-el:text var=${customer.id}
property=customers[${status.index}]/
/c:forEach
could do the trick, as long as you scanned both the var and property
attributes for expressions.
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: Struts-EL: Ideas about name and indexed name attributes?
Craig == Craig R McClanahan [EMAIL PROTECTED] writes:
Craig I've been thinking about this issue as well, as you might imagine.
Craig For general form field properties, I'm assuming that we would have to make
Craig the existence of the form bean explict -- say, for example:
Craig html-el:test var=${logonForm.username}/
Craig instead of assuming that you could just use username and know that it
Craig was resolved against the form bean in the surrounding scope. The property
Craig name can either be inferred from the expression (i.e. after the first
Craig period), or we could allow an optional property attribute that would
Craig provide the field name for the rendered input field.
I'm very hesitant to start parsing the EL string, as there's a lot of different
ways to form a legal expression, and I don't want to try to restrict the form
of the EL expression in these situations.
We could of course have the var attribute be an EL to get the current value,
and have the property attribute be the name attribute in the generated
HTML, but then you have a disconnect between the value and the name, whereas
the current name/property pair allows a clean specification of both the
current value and the request parameter name.
Craig For indexed things, remember that the subscript in an EL expression can be
Craig a variable. So something like this should work, where customers is an
Craig array of customer objects, and we're inside a form with a field per
Craig customer account number:
Craig c:forEach var=customer items=customers varStatus=status
Craig html-el:text var=${customer.id}
Craig property=customers[${status.index}]/
Craig /c:forEach
Craig could do the trick, as long as you scanned both the var and property
Craig attributes for expressions.
Yes, I had considered the array index possibility. This will provide more
flexibility, allowing the case of two nested iterate tags, and you want the
property attribute of the HTML tag to come from the OUTER iterate tag (which
someone on struts-user just asked about today).
However, in the general case, we're still having the users specify more, and
redundant information, just to avoid the use of the name/property pair.
I guess we could provide two ways to do this:
If the name attribute is present, the name and property are combined as
usual. However, if the var attribute is present, in place of the name
attribute, then the var value is used for the current value, and the
property attribute is used as the entire name attribute (of the generated
HTML).
(It's certainly confusing to have the name attribute mean two different
things, one in JSP, and the other in HTML).
Unfortunately, a change like this will require changing the base Struts tag.
In the case of CheckboxTag (and probably others), the current value lookup is
done directly in its doStartTag() method, with no comparison of value
against null check to bypass it (which is the case in other tags, like size
and message, for instance).
--
===
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]
