On Jan 30, 2009, at 1:10 AM, Jacopo Cappellato wrote:
On Jan 29, 2009, at 11:56 PM, Adam Heath wrote:
I am a few days behind, but here is my take on this problem.
Move Party/PartyType to framework; leave Person/PartyGroup in
applications/party(along with the seed data). The framework then
just
deals with some abstract party, it has no idea what the exact kind of
party it is dealiing with.
Party is a *very* low-level critical entity; I don't think we can get
away from not requiring it in framework.
This is an interesting idea, but I am not sure we will have to go in
this direction.
I'd suggest to try to live without it, and postpone the decision.
In the meantime we may move the common "ERP-oriented" resources to
an "applications/appcommon" (another name could be "commonext", to
use the same pattern used for security/securityext and entity/
entityext) component and leave the common "framework-oriented" ones
in the "framework/common" component.
Well, initially we should just move to the "applications/appcommon"
component the resources that are causing a dependency from the
framework to the applications.
I like the commonext name better than appcommon, I forgot about that
pattern.
In general I'd rather see things from the framework go into the
applications than see something like Party go into the framework/
common component. In many cases where party is currently referenced in
the framework this may not help anyway, as many things refer to stuff
other than just the Party/partyId.
Anyway, I'm still not comfortable with moving all of the entity defs
currently in framework/common to applications/commonext. We have a lot
of code and a few entities for doing basic things (and by basic I mean
OS and language types of features, ie things Java supports) like
selecting languages and locales and supporting enumerations stored in
the database (as opposed to "hard coded") or modeling states and valid
state changes. IMO all of those make much more sense as part of the
framework.
-David
