This EOModel subclass primarily provides the opportunity to subclass EOEntity.
Note the package com.webobjects.eoaccess is used to allow any protected or default access superclass instance methods to resolve at runtime.
To allow for extended prototypes set er.extensions.ERXModel.useExtendedPrototypes=true. Note: this may be incompatible with {@link er.extensions.eof.ERXModelGroup#flattenPrototypes}.
The existence of prototype entities based on specific conventions is checked and the attributes of those prototype entities are added to the model's prototype attributes cache in a specific order. The search order ensures that the same prototype attribute names in different prototype entities get chosen in a predictable way.
Consequently, you can use this search order knowledge to over-ride Wonder's ERPrototypes for your entire set of application eomodels or just for specific named eomodels.
To understand the variables used in deriving the prototype entity names that are searched a few definitions are appropriate
- <pluginName>
- Relates to the database type. Examples of pluginName are MySQL, Derby, FrontBase, OpenBase, Oracle, Postgresql
- <adaptorName>
- Relates to the general persistence mechanism. Examples of adaptorName are JDBC, Memory, REST
- <modelName>
- The name of an eomodel in your app or frameworks
The priority order (which is basically the reverse of the search order) for prototype entities is as follows:
- EOJDBC<pluginName><modelname>Prototypes
- EO<adaptorName><modelname>Prototypes
- EO<modelname>Prototypes
- EOJDBC<pluginName>CustomPrototypes
- EO<adaptorName>CustomPrototypes
- EOCustomPrototypes
- EOJDBC<pluginName>Prototypes (Available for popular databases in ERPrototypes framework)
- EO<adaptorName>Prototypes (ERPrototypes has some of these too for generic-JDBC, Memory, etc.)
- EOPrototypes (Without ERXModel and the extendedPrototypes, this was pretty much your only way to add your own prototypes alongside ERPrototypes)
@author ldeck