Different customers want to store different kinds of data on their
agreements and its items. For us, the easiest way is to extend the entities and add new fields to the forms. The drawback is that the entity and forms will end up containing all custom fields. The other option is to use attributes. Attributues can be configured per customer but the drawback of attributes is that there is no type checking, validation or the use of dropdowns. I'm starting to design a more advanced attributes mechanism but before doing that I was wondering if I might be missing something and not trying to solve a non-existing problem. Best, Jeroen van der Wal Stromboli b.v. +31 655 874050 |
I don't know if this is the best approach, but it is the one I use. Instead of extending the entity, I create a separate entity that contains the additional fields. Then I connect the original entity and the new entity together with a view entity. The CRUD services for the view entity call the original entity's CRUD services first, and then call the new entity's CRUD services. In this way I keep all custom entities and code outside of the main project.
-Adrian --- On Thu, 4/1/10, Jeroen van der Wal <[hidden email]> wrote: > From: Jeroen van der Wal <[hidden email]> > Subject: What's the best approach for custom fields: attributes vs extending entities? > To: "user" <[hidden email]> > Date: Thursday, April 1, 2010, 4:16 AM > Different customers want to store > different kinds of data on their > agreements and its items. For us, the easiest way is to > extend the > entities and add new fields to the forms. The drawback is > that the > entity and forms will end up containing all custom fields. > The other > option is to use attributes. Attributues can be configured > per > customer but the drawback of attributes is that there is no > type > checking, validation or the use of dropdowns. I'm starting > to design a > more advanced attributes mechanism but before doing that I > was > wondering if I might be missing something and not trying to > solve a > non-existing problem. > > Best, > > Jeroen van der Wal > Stromboli b.v. > +31 655 874050 > |
While we typically extend the entities which works for us (we leverage the existing services implementations but usually do not leverage the existing presentment layer). One thing to consider is if your extension really represents a sub-class of the parent entity (think Person/PartyGroup extending Party) you could make use of an additional type with the "hasTable" attribute set to Y. One enhancement that would be nice is the ability to have Ofbiz understand entity inheritance and perform table joins under the covers (aka standard ORM tools like Hibernate). |
Bob Morley wrote:
> Adrian Crum-2 wrote: >> I don't know if this is the best approach, but it is the one I use. >> Instead of extending the entity, I create a separate entity that contains >> the additional fields. Then I connect the original entity and the new >> entity together with a view entity. The CRUD services for the view entity >> call the original entity's CRUD services first, and then call the new >> entity's CRUD services. In this way I keep all custom entities and code >> outside of the main project. >> > > While we typically extend the entities which works for us (we leverage the > existing services implementations but usually do not leverage the existing > presentment layer). Your approach is probably best. I think the approach I use was developed before the entity extension capability was introduced, and now I do it that way out of habit. |
Free forum by Nabble | Edit this page |