On Jan 30, 2009, at 2:11 AM, Jacopo Cappellato wrote:
On Jan 30, 2009, at 10:39 AM, David E Jones wrote:
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
Yes, I agree that entities like Enumeration should stay in the
framework/common component; and in general, I think that we should
not move any entity to commonext (aka applications/common) at least
initially: we should just use the new component to fix the
dependency issue we have right now.
I guess I missed something about the commonext idea... which
dependency issues would we use it to fix? I'll admit I haven't tried
to create a list of all of the dependency issues, but the ones like
the Party issues and such should go in the party component and
probably not anywhere else.
The one that Hans brought up with the various header things might be a
good reason to have something in this component, but actually I like
the idea better of having it in the database somewhere, perhaps using
the portal stuff. That would give us a way to have a default set of
things to show there and a way to let users customize it. It would
also give us a way to have each component setup the data for the
header portlets it offers in seed data, instead of in a file somewhere.
-David
