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

[Adrian Crum <ad...@yahoo.com>]

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 <je...@stromboli.it> wrote:

> From: Jeroen van der Wal <je...@stromboli.it>
> Subject: What's the best approach for custom fields: attributes vs extending  entities?
> To: "user" <us...@ofbiz.apache.org>
> 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
> 


      

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

[Adrian Crum <ad...@hlmksw.com>]

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.

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

[Bob Morley <rm...@emforium.com>]

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).
-- 
View this message in context: http://n4.nabble.com/What-s-the-best-approach-for-custom-fields-attributes-vs-extending-entities-tp1747938p1748168.html
Sent from the OFBiz - User mailing list archive at Nabble.com.