Re: Support for submitting unchecked checkboxes
Yes but how do you set that hidden field if the checkbox value changes? You must also use javascript then i believe johan - Original Message - From: "Howard Moore" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 22, 2001 11:04 AM Subject: RE: Support for submitting unchecked checkboxes One problem with this is that it fails if javascript is disabled on the client. An alternative hack would be to have a hidden field and the checkbox both with the same name and have Struts process them as a special case when populating the ActionForm. -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED]] Sent: 22 February 2001 09:03 To: [EMAIL PROTECTED] Subject: Re: Support for submitting unchecked checkboxes +1 Please insert this (or something like this) in the 1.0 code base, because checkboxes are useless at this time to use!! johan - Original Message - From: "Laine Donlan" [EMAIL PROTECTED] To: "Struts Dev (E-mail)" [EMAIL PROTECTED] Sent: Tuesday, February 20, 2001 2:19 PM Subject: Support for submitting unchecked checkboxes In order to capture the act of a user unchecking checkboxes and to initialize the checkbox as checked/unchecked with non boolean values I made a couple of changes to the org.apache.struts.taglib.html.CheckboxTag. Basically the changes consisted of: 1) Using the supplied value attribute to match against the bean property value and generating the 'checked' attribute accordingly. If the value is not supplied then the previously implemented method of checking 'on', 'true', or 'yes' is performed. So I do not think that default behavior should be affected. 2) Added support for two new attributes - submitUnchecked (boolean) and uncheckedValue (String). Neither of these attributes are required and the submitUnchecked defaults to 'false'. If a user chooses to submit unchecked values then two form inputs will be generated that facilitate this function. See below for an example: Tag notation - html:checkbox name="bean" property="indexedBean.property" submitUnchecked="true" uncheckedValue="0" value="1"/ Generated HTML - input type="checkbox" name="indexedBean.property_checkBox" value="1" onclick="(this.checked?this.form['indexedBean.property'].value ='1':this. form['indexedBean.property'].value='0')" input type="hidden" name="indexedBean.property" value="0"/ (where 0 is the current value of the bean property) So in this scenario the actual checkbox param in the request will be ignored and the hidden input will be used to maintain the bean property that the user wishes. In the case where the user does not provide the two new attributes the html will be generated as it is today with the exception of the determination of the checked or unchecked mentioned above. I could not see how this functionality was present in the current checkbox tag without explicitly declaring two tags and adding javascript to the checkbox tag. Even then some scripting may be required to differentiate between the two inputs and to initialize the hidden one. If I missed something could someone point me in the right direction. I have attached the CheckboxTag.java file for review and use if anyone is interested. CheckboxTag.zip Thanks. Comments would be appreciated. Laine
RE: Support for submitting unchecked checkboxes
You don't change the hidden field at all. For example, given the following html; input type="hidden" name="checkbox" value="off"/ input type="checkbox" name="checkbox" If the checkbox is unchecked the value "checkbox=off" would be part of the submitted request. If the checkbox is checked the value would be "checkbox=offcheckbox=on". The code that populates the ActionForm would then have to be modified to set the boolean "checkbox" property to false only if it had not already been set to true. -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED]] Sent: 22 February 2001 10:23 To: [EMAIL PROTECTED] Subject: Re: Support for submitting unchecked checkboxes Yes but how do you set that hidden field if the checkbox value changes? You must also use javascript then i believe johan - Original Message - From: "Howard Moore" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 22, 2001 11:04 AM Subject: RE: Support for submitting unchecked checkboxes One problem with this is that it fails if javascript is disabled on the client. An alternative hack would be to have a hidden field and the checkbox both with the same name and have Struts process them as a special case when populating the ActionForm. -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED]] Sent: 22 February 2001 09:03 To: [EMAIL PROTECTED] Subject: Re: Support for submitting unchecked checkboxes +1 Please insert this (or something like this) in the 1.0 code base, because checkboxes are useless at this time to use!! johan - Original Message - From: "Laine Donlan" [EMAIL PROTECTED] To: "Struts Dev (E-mail)" [EMAIL PROTECTED] Sent: Tuesday, February 20, 2001 2:19 PM Subject: Support for submitting unchecked checkboxes In order to capture the act of a user unchecking checkboxes and to initialize the checkbox as checked/unchecked with non boolean values I made a couple of changes to the org.apache.struts.taglib.html.CheckboxTag. Basically the changes consisted of: 1) Using the supplied value attribute to match against the bean property value and generating the 'checked' attribute accordingly. If the value is not supplied then the previously implemented method of checking 'on', 'true', or 'yes' is performed. So I do not think that default behavior should be affected. 2) Added support for two new attributes - submitUnchecked (boolean) and uncheckedValue (String). Neither of these attributes are required and the submitUnchecked defaults to 'false'. If a user chooses to submit unchecked values then two form inputs will be generated that facilitate this function. See below for an example: Tag notation - html:checkbox name="bean" property="indexedBean.property" submitUnchecked="true" uncheckedValue="0" value="1"/ Generated HTML - input type="checkbox" name="indexedBean.property_checkBox" value="1" onclick="(this.checked?this.form['indexedBean.property'].value ='1':this. form['indexedBean.property'].value='0')" input type="hidden" name="indexedBean.property" value="0"/ (where 0 is the current value of the bean property) So in this scenario the actual checkbox param in the request will be ignored and the hidden input will be used to maintain the bean property that the user wishes. In the case where the user does not provide the two new attributes the html will be generated as it is today with the exception of the determination of the checked or unchecked mentioned above. I could not see how this functionality was present in the current checkbox tag without explicitly declaring two tags and adding javascript to the checkbox tag. Even then some scripting may be required to differentiate between the two inputs and to initialize the hidden one. If I missed something could someone point me in the right direction. I have attached the CheckboxTag.java file for review and use if anyone is interested. CheckboxTag.zip Thanks. Comments would be appreciated. Laine
Re: PROPOSAL - Testing Framework
"Craig R. McClanahan" wrote: Rob Leland has volunteered to take the lead on this, but I don't know if anything specific has happened yet. Not only am I willing to Lead but to follow, since Vince obviously has MUCH more experience with J2EEUnit testing than me. I have a handle on JUnit, but not J2EEUnit , ... Yet :). Nothing has been put in place, I have started looking at the action classes had hoped to get a few tests in by version 1.0, with the bulk of the tests for version 1.1. So Vince what would you propose for directory structures, organizing tests ? It looked like you had some good suggestions yesterday. -Rob
Re: PROPOSAL - Testing Framework
Give me until tomorrow and I'll come up with a structure, organization, and some tests proposals ... :) Thanks. Vincent. - Original Message - From: "Rob Leland" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 22, 2001 9:47 PM Subject: Re: PROPOSAL - Testing Framework "Craig R. McClanahan" wrote: Rob Leland has volunteered to take the lead on this, but I don't know if anything specific has happened yet. Not only am I willing to Lead but to follow, since Vince obviously has MUCH more experience with J2EEUnit testing than me. I have a handle on JUnit, but not J2EEUnit , ... Yet :). Nothing has been put in place, I have started looking at the action classes had hoped to get a few tests in by version 1.0, with the bulk of the tests for version 1.1. So Vince what would you propose for directory structures, organizing tests ? It looked like you had some good suggestions yesterday. -Rob
RE: building struts
Rob, That seems like a JAXP problem to me. Make sure you don't have parser.jar in your classpath, and no other application uses jaxp.jar from JAXP 1.0 -Original Message- From: Rob Leland To: [EMAIL PROTECTED] Sent: 2/22/01 3:50 PM Subject: building struts Ok: I am trying to build struts Feb 22 using: ant 1.3-b3, options.jar (1.3 b3); jaxp 1.1 I haven't been sucessfull yet. Which version of ant are you using to build struts. Have you tried gump ? BUILD FAILED java.lang.SecurityException: sealing violation at java.net.URLClassLoader.defineClass(URLClassLoader.java:234) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:117 ) at org.apache.tools.ant.ProjectHelper.getParserFactory(ProjectHelper.java:7 06) at org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:105) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:8 5) at org.apache.tools.ant.Main.runBuild(Main.java:403) at org.apache.tools.ant.Main.main(Main.java:149)
ClassLoader used in Digester
We are currently using the digester in a server we build that uses custom classloaders for some containers within it, which load custom apps. We use the Digester in the server itself, and some of the apps being loaded in the containers also want to use the Digester. The problem is that when an app creates a Digester instance, it is created by the parent (system) classloader that loaded the server, since the server had already used the Digester and that classloader knows about it. When the Digester then does a Class.forName in one of its rules to create an object, it knows nothing about the container's ClassLoader and the classes within it. The class is only withing the app, and so can't be found. Is there any downside to changing the Digester to always use: Thread.getCurrentThread.getContextClassLoader.loadClass(name); instead of class.forName(name); The code would no longer work in JDK 1.1, but that is already the case...
Weblogic 6.0/Template Tags and release method
I am not sure if this has come up on the list recently but it seems that there is a minor bug in the template tags in Weblogic 6.0. I think the problem arises when using multiple template:inserts are used within a single page. The InsertTag creates it's content map during instantiation and weblogic 6.0 only instantiates the object once per page. Therefore, in the release() method of the InsertTag the map when the map is set to null, the next time the object is used a NullPointer is thrown. I was able to get around this by either checking for null in the doStartTag of the Insert or by resetting the instance of the map in the release rather than setting it to null. Thanks Laine
