David E Jones wrote: > > Adam, > > It's pretty clear you like this idea and don't want to back down, so I'm > not going to push back.
It's been a problem for me(and Ean, my coworker) since we started using OfBiz. It's not something new. It's made our job *more* difficult. > What is wrong with the code already in the GenericEntity.java file that > does this boolean conversion? > As far as making it a best practice goes... maybe you should read > through the best practices list and see if you can find where it might > for it. For form, screen, tree, and menu widgets and for simple-methods > it's a non-issue as Y/N are actually easier and less confusing (zero > mapping beats single mapping any day). This only has an effect for > business logic written Java, and I think that's a bad idea in the first > place. What do you mean, by zero-mapping vs single-mapping? When I see code that compares a value to Y/N, I assume it's a single-character string field, and can store any single character. A boolean comparison, on the other hand, tells me exactly what the field holds. > So: > > 1. small issue; not going to save anyone any significant amount of time For those that have dealt with OfBiz from the beginning, you are right, that this will hurt their knowledge of the framework. However, new users coming into the system have no idea about what the Y/N stuff is about; they deal with java objects, and those are booleans. We *want* new people to use OfBiz. And this special case will cause them grief. > 2. bad for the best practices tools > > If you want to argue with the best practices... feel free to start up a > thread, just try to keep in mind limited resources, better things to > work on for EVERYONE, and general ROI (starting with proving any sort of > return, before even thinking about the investment required). Switching to boolean values for boolean fields *will* reduce the code on the system. Another point; in lots of simple method definitions, there are blocks for doing CRUD to entities; in the vast majority of cases, these method definitions are *identical*, except for the entity name and property to pull error messages from. This points to a need to refactor. > http://docs.ofbiz.org/display/OFBADMIN/Best+Practices+Guide Nothing about booleans there. And it mentions CVS, which is years out of date. And what is OOTB? It's used, but never defined.
