On Mar 21, 2011, at 2:34 AM, David E Jones wrote: > > On Mar 20, 2011, at 10:02 AM, Joe Eckard wrote: > >> >> On Mar 19, 2011, at 11:33 PM, David E Jones wrote: >> >>> >>> I'm writing this to start a thread to discuss: >>> >>> If you could change ANYTHING in the OFBiz data model, what would it be? >>> >>> To kick this off here are some ideas I've compiled that have come up over >>> the years (many based on feedback from people on this mailing list), or >>> that I thought of recently will working on this topic. You can see them >>> below... >>> >>> -David >>> >>> ======================================================== >>> >>> >>> - Move most *Type entities to Enumeration values (update seed data, >>> referring >>> entities, remove *Type) (after this remove all remaining hasTable fields) >> >> Related to this: >> >> - Add the enumTypeId to the entity definition for the field >> >> <field name="locationTypeEnumId" enum-type="FACLOC_TYPE" ... > > That's an interesting idea, make the framework aware of the > EnumerationTypes... > > What I'm thinking of instead would be to use a convention, basically have the > relation(ship).@title attribute be the enumTypeId (and use CamelCasing for > the enumTypeIds). >
That would work also, anything that would let you determine the type to look for. When I was building a generic entity editor in wicket, not being able to determine this programmatically was a big problem. >> Also, >> >> - Make userLoginId an ID that isn't changed, add a field for "name" that can >> be updated > > Yeah, that's a good idea. I like it enough that I just changed Moqui to work > that way. > > Right now OFBiz has a work-around for changing usernames by creating a new > UserLogin record and attaching it to the same Party. Since most stuff in the > system records by party this works okay, but it's true that there is still a > lot of stuff attached to the userLoginId that wouldn't be carried over, so > this approach you're talking about is clearly better. > > >> - Condense credit card name fields (first, middle, last, prefix, suffix, >> etc.) into a single "nameOnCard" > > This one I'm not so sure about. The OFBiz CreditCard entity actually started > out with a single field for the name on card (and one for the company name on > card), and then we ran into a problem where certain payment processors ask > for separate first/middle/last names, and splitting based on spaces is not > reliable (especially for those with multiple last names, etc). > You're right, I didn't look into the other payment processors. I've worked with several large ones in the past and they all either didn't use the name, or accepted a single name field and I was concerned about the re-assembled name not matching what someone could have entered as a single string. > Is there are particular reason you've found the separated fields annoying? > > -David > >
