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 <[email protected]> wrote: > From: Jeroen van der Wal <[email protected]> > Subject: What's the best approach for custom fields: attributes vs extending > entities? > To: "user" <[email protected]> > 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 >
