Properties with names like "isSent" pass my test using getters & setters like getIsSent() setIsSent(xxx)
Testing property named 'isSent' [PASS] Set isSent to 'Test Value' [PASS] isSent=Test Value :-) -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 17, 2002 21:43 To: Struts Users Mailing List Subject: RE: A question on ActionForm property nomenclature as regards multiple contiguous capitalised characters Ive done some testing and it seems I _CANNOT_ use names like this for properties. Given an action form for the properties: normalField rGDocId rNodeId dTImport Running a simple test using property utils gives the following: (Where normalField is a sort of control for the experiment as its the one we expect to have no troubles) Testing property named 'normalField' [PASS] Set normalField to 'Test Value' [PASS] normalField=Test Value Testing property named 'rNodeId' [FAIL] COULDNT SET PROPERTY 'rNodeId' [FAIL] COULDNT READ PROPERTY 'rNodeId' Testing property named 'rGDocId' [FAIL] COULDNT SET PROPERTY 'rGDocId' [FAIL] COULDNT READ PROPERTY 'rGDocId' As we can see, 'normalField' works sweet, but our funny named propertys do not. This is almost certainly because the bean conventions interpret a getter named getRNodeId as being for a property 'RNodeId' and NOT 'rNodeId' - runs of 2 capitalised letters does not result in decapitalisation. This is illustrated by the following output on same form bean: Testing property named 'RNodeId' [PASS] Set RNodeId to 'Test Value' [PASS] RNodeId=Test Value Testing property named 'RGDocId' [PASS] Set RGDocId to 'Test Value' [PASS] RGDocId=Test Value Personally I would have made the specs such that BOTH rNodeId and RNodeId were acceptable ways to access that property, however I didnt, and they arent. :-( The code for my test is as follows (excluding my top secret package name). Without doubt your email client will format it unreadably to your primitive non-digital minds <mu-ha-ha-ha/>: import org.apache.struts.action.*; import org.apache.commons.beanutils.PropertyUtils; public class TestPU extends ActionForm { // String value to test with public static final String TEST_VALUE = "Test Value"; // Property storage variables private String _rGDocId; private String _normalField; private String _rNodeId; private String _dTImport; // Bean getter & setter methods public void setRGDocId(String value) { _rGDocId = value; } public String getRGDocId() { return _rGDocId; } public String getRNodeId() { return _rNodeId; } public void setRNodeId(String value) { _rNodeId = value; } public void setNormalField(String value) { _normalField = value; } public String getNormalField() { return _normalField; } public void setDTImport(String value) { _dTImport = value; } public String getDTImport(String value) { return _dTImport; } // Testing methods............... public static void main(String[] args) { TestPU bob = new TestPU(); testField(bob,"normalField"); testField(bob,"rNodeId"); testField(bob,"rGDocId"); testField(bob,"RNodeId"); testField(bob,"RGDocId"); } private static void testField(TestPU bob, String property) { System.out.println("Testing property named '" + property + "'"); try { PropertyUtils.setSimpleProperty(bob,property,TEST_VALUE); System.out.println(" [PASS] Set " + property + " to '" + TEST_VALUE + "'"); } catch(Throwable t) { System.out.println(" [FAIL] COULDNT SET PROPERTY '" + property + "'"); //t.printStackTrace(); } try { System.out.println(" [PASS] " + property + "=" + PropertyUtils.getSimpleProperty(bob,property)); } catch(Throwable t) { System.out.println(" [FAIL] COULDNT READ PROPERTY '" + property + "'"); //t.printStackTrace(); } System.out.println(); } } -----Original Message----- From: Max Cooper [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 17, 2002 18:47 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: A question on ActionForm property nomenclature as regards multiple contiguous capitalised characters I don't know quite what will happen for you, but if you can stand adding them one at a time, or inspecting what properties get set on your form submittals (and which don't), you might have to plow through it that way. This does remind me of an idea I had while working on a couple of pages. I think it might be of use to you given the "bad" names you have to deal with. In the interest of keeping the property names short to keep the URL from being too long on a GET, we created some properties like toM, toD, and toY. It seemed like it might be useful to create two sets of getters/setters for the same property; the more readable property names for these would be toMonth, toDate, toYear, for instance. In this example, setToM() and setToMonth() would set the same variable inside the ActionForm class. HTTP imposes no maximum limit on the length of a URL, but some implementations and network bandwidth usage suggest that there is value in keeping the names short (though clearly there is the competing goal of making them readable, which tends to make them long). 255 was suggested as a goal, but we often spilled over that limit and haven't experienced any problems. Yes, I know I could use a POST to keep these out of the query string, but POSTs yield less than ideal behavior in many circumstances. You can't bookmark or redirect a user back to a POST, and browsers don't behave nicely when you use the Back button with POSTs. For searches, for instance, we want to use GETs. Has anyone used this technique (short & long names for the same property)? Do you have any insight gained from that experience (was it worth it, did it just add confusion, ran into trouble when..., etc.)? -Max ----- Original Message ----- From: "Andrew Hill" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, August 17, 2002 2:41 AM Subject: A question on ActionForm property nomenclature as regards multiple contiguous capitalised characters > One of the ActionForms I have to do (by Monday AM) needs to have a bunch of > fields with nasty names such as: > rNodeId > uDocNum > isViewAckReq > > etc.... > Its got 62 fields and all but a few look like this. - Kill me. Pleaseeeeee > :-( > > (These property names are defined in various places (by other developers) > and if I want to have them changed its a b****y nuisance.) > > Before I rush out and waste time coding the 60+ getters and setters: (ie: > > String getRNodeId() > void setRNodeId(String value) > > String getUDocNum() > void setUDocNum(String value) > > String getIsViewAckReq() > void setIsViewAckReq() > > (I handle my checkboxes with strings too. Just because it is a boolean value > in the DAO doesnt mean that it uses a checkbox on the screen. It might (yeh > right) use an <input> in which case, as with any other data type I need to > preserve the users garbage input for them to correct after validation)) > > , I need to know how well are such property names going to work with all the > dodgy capitalisation when I use them with PropertyUtils and when the form is > populated from the request? > > My understanding of the bean conventions (regarding capitalisation of the > first two letters) > http://java.sun.com/products/javabeans/docs/beans.101.pdf > leads me to believe that for a getter named getRNodeId() the bean is > expecting the property named RNodeId and not rNodeId, or would both these > property names map to the getRNodeId() getters and setters? > > And the other question, is having the word "is" tacked to the front of the > property name (resulting in getters such as getIsXxx or isIsXxx) going to > cause the bean stuff to go funny on me? > > So, can I use these property names, or do I have to go kick some heads and > get them changed? > > > -- > 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]> -- 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]>
