On 10/2/2012 1:13 AM, Scott Gray wrote:
On 1/10/2012, at 7:14 PM, Adrian Crum wrote:
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.
To be honest I don't think this is a good reason to change anything. A basic
and fundamental misunderstanding of the data model isn't a reason to drive
change in anything except perhaps better documentation.
*Type entities also provide some flexibility by allowing additional fields to
be used to describe common behavior of various types such as ProductType's
isDigital and isPhysical, personally this is a feature of the design that I'd
like to see put into greater use. An example of that might be having a
defaultDataResourceTypeId or defaultMimeTypeId on ProductContentType so that
the most appropriate form for the given ProductContentType can be displayed,
currently that sort of thing is hardcoded into a groovy script if I recall
correctly.
There are better ways to handle those datums. isDigital and isPhysical
are product features. ProductContentType does not describe an entity
subtype - so that entity will not change.
I could create a list of which entities implement subtypes - maybe that
will help clear up any confusion.
Perhaps in the future strong use of those fields could lay a better foundation
for allowing user's to create their own types simply by indicating the desired
behaviors.
Regards
Scott
