The user will not see the EntitySubtype entity because it will not be a
part of the UI. In other words, a user can't add new subtypes. There can
be a UI in Web Tools for adding entity subtypes, but like I said, it
will clearly describe the pattern and the correct usage.
-Adrian
On 10/1/2012 10:14 AM, Olivier Heintz wrote:
For the user (or developers) who not understand that pattern, I think
it will not more clear.
But, on a Data Model perspective I prefer only one entity than multiple.
With one entity, it will be possible to have only one entity for
EntitySubTypeAttr and EntityAttr and so having a generic User
interface (user configurable portlet) which will be usable.
In the EntitySubtype, I will add the field hasTable, to generalize the
same concept as Party with Person and PartyGroup, only the fields uses
by all type in Party and specifics Field in dedicated entity.
Example : It will be necessary to have same things for WorkEffort
So, +1 for your idea as a first step ;-)
Olivier
Le 01/10/2012 08:14, Adrian Crum a écrit :
I mentioned this once before as part of another discussion, but I'm
creating a new discussion so it can receive the attention it deserves.
The Data Model Resource Book describes entity subtypes. OFBiz
implements entity subtypes by adding a field to the supertype that
points to a *Type entity that contains valid subtypes.
The problem is users (and some developers) do not understand that
pattern, and they add invalid subtypes to the *Type entity. That can
cause things to break. As an example, I have a client who created
additional ProductTypes (that actually represented product
categories) and used those added ProductTypes for their products.
Then they were puzzled why their order fulfillment process stopped
working.
I think what we need is an EntitySubtype entity to store the subtype
data. Instead of multiple *Type entities, we would have a single
EntitySubtype entity, and the supertypes will point to it. The
supertype field could be called something like entitySubtypeId. The
EntitySubtype entity will be clearly documented as to its purpose and
proper use.
EntitySubtype
-------------
entityName*
entitySubtypeId*
description
What do you think?
-Adrian
