[ http://mc4j.org/jira/browse/STS-460?page=comments#action_11035 ] Phil Sladen commented on STS-460: ---------------------------------
Hi, I'm new to JIRA and when I submitted this issue I didn't mean it to be described as a 'bug', and certainly not 'major', sorry. I think if Sun applied the same logic to the Java language then we would have ended up with expressions such as 'string1.concat(string2.concat(string3))' etc. instead of 'string1 + string2 + string3' ;) All the web projects I have worked so far have never (except for the odd special cases) defined a DB column for a form text field as nullable. The simplest convention to use is that empty text fields result in empty String types (and not null ones). Some reasons are: - most importantly, you don't have to check for null Strings everywhere and NPEs with String types becomes virtually non-existent. - some, if not all, JDBC drivers require that a null String be set on a row with setNull(), so it has to be explicitely checked for. Ok, this is irrelevant f you are using a persistence API :) I am a big fan of consistency, but IMHO sometimes not at the expense of simplicity. How about a quick straw poll about this, or even including such a property binder for those like myself? Thanks again. > Empty form text fields give null String values > ---------------------------------------------- > > Key: STS-460 > URL: http://mc4j.org/jira/browse/STS-460 > Project: Stripes > Issue Type: Improvement > Components: ActionBean Dispatching > Affects Versions: Release 1.4.3 > Environment: Windows/Linux, Tomcat 5.5.25 > Reporter: Phil Sladen > Assigned To: Tim Fennell > > I can understand that empty form fields give rise to empty objects when there > is a converter involved and invalid input, but it seems a bit OTT to also > treat Strings the same way. Although String is not a native type, it is > treated as such in some respects in the language, and I think Stripes should > do the same by default. Otherwise, code is going to be littered with checks > for null or be forced to use something like StringUtils. I would however > expect the String to be left unaltered, and possibly null, if the > corresponding parameter is not provided in the request. I could then choose > whether such extra checks are warranted for Strings as well as other objects. > Instead, I found the most convenient way around the issue was to provide my > own PropertyBinder: > public class MyPropertyBinder extends DefaultActionBeanPropertyBinder { > protected void bindNullValue(ActionBean bean, String property, Class > type) > throws ExpressionException { > if (type == String.class) { > BeanUtil.setPropertyValue(property, bean, new > String()); > } > else { > super.bindNullValue(bean, property, type); > } > } > } > All credit due to Stripes extensibility, but I don't think I should have to > do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://mc4j.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Stripes-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-development
