GenericDelegator factory lookup methods

[Adam Heath-2]

I realized a major issue with the Delegator lookup functions.  The
goal is to make switching delegators easier.  However, there are still
several hard-coded things that need to be detached.

The rest of the system will continue to use EntityCondition objects.
Those must *not* be connected to any delegator.

The rest of the system will continue to use ModelEntity, and
DynamicViewEntity.  The reason why these are tightly connected to the
delegator, is because it's the delegator that is
responsible(indirectly) for reading in the xml configuration.  It
would be nice to completely decouple the model from the delegator, so
other delegator implementations could be used.

Additionally, it'd be nice to decouple the xml reader from the
in-memory ModelEntity, so that they(ModelEntity) could be created thru
other means.  Currently, you *must* create ModelEntity/ModelViewEntity
by using xml Element; this is poor.

I'm wanting to do more pur-sql implementations, using the sql parser
stuff I've hinted at for years.  These changes are a step in the right
direction, but there is still too much coupling going on.

Does anyone else see this issue, or do I need to explain it more?

ps: I have some changes for the view loading to decouple a bit more
from xml(basically by adding more constructors).  The next step would
then to be to remove the xml parsing from the classes, into a separate
class, so the in-memory model is *just* for describing the data, not
for reading.  It would then be possible to segment the code base(by
building separate jars), so that unused code wouldn't even need to be
on the system.

[Adrian Crum]

I agree that work needs to be done on the delegator. The static (cached)
data needs to be separated from the rest of the class. If the XML data
was converted to lightweight Java data structures, then various classes
could reference those data structures without having to go through the
delegator or model classes. Also, it would be helpful to have the data
structures include visitor methods.

-Adrian

Adam Heath wrote:

> I realized a major issue with the Delegator lookup functions.  The
> goal is to make switching delegators easier.  However, there are still
> several hard-coded things that need to be detached.
>
> The rest of the system will continue to use EntityCondition objects.
> Those must *not* be connected to any delegator.
>
> The rest of the system will continue to use ModelEntity, and
> DynamicViewEntity.  The reason why these are tightly connected to the
> delegator, is because it's the delegator that is
> responsible(indirectly) for reading in the xml configuration.  It
> would be nice to completely decouple the model from the delegator, so
> other delegator implementations could be used.
>
> Additionally, it'd be nice to decouple the xml reader from the
> in-memory ModelEntity, so that they(ModelEntity) could be created thru
> other means.  Currently, you *must* create ModelEntity/ModelViewEntity
> by using xml Element; this is poor.
>
> I'm wanting to do more pur-sql implementations, using the sql parser
> stuff I've hinted at for years.  These changes are a step in the right
> direction, but there is still too much coupling going on.
>
> Does anyone else see this issue, or do I need to explain it more?
>
> ps: I have some changes for the view loading to decouple a bit more
> from xml(basically by adding more constructors).  The next step would
> then to be to remove the xml parsing from the classes, into a separate
> class, so the in-memory model is *just* for describing the data, not
> for reading.  It would then be possible to segment the code base(by
> building separate jars), so that unused code wouldn't even need to be
> on the system.
>