What's the best approach for custom fields: attributes vs extending entities?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

What's the best approach for custom fields: attributes vs extending entities?

Jeroen van der Wal
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
Reply | Threaded
Open this post in threaded view
|

Re: What's the best approach for custom fields: attributes vs extending entities?

Adrian Crum-2
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
>


     
Reply | Threaded
Open this post in threaded view
|

Re: What's the best approach for custom fields: attributes vs extending entities?

Bob Morley
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).

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).
Reply | Threaded
Open this post in threaded view
|

Re: What's the best approach for custom fields: attributes vs extending entities?

Adrian Crum
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.