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.
