[jira] [Commented] (CAY-1603) Improve custom ExtendedType registration API

["Andrus Adamchik (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAY-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093239#comment-13093239 ] 

Andrus Adamchik commented on CAY-1603:
--------------------------------------

I just checked the patch... so when splitting ExtendedTypeMap into interface and implementation we should've probably ensured that all callers of ExtendedTypeMap are using the new interface instead of the DefaultExtendedTypeMap (meaning a much smaller patch and dependency on interface, not implementation). But anyways...  I think even in this form, the implementation is somewhat clunky. And I have some ideas on redoing it using our recently documented Cayenne runtime extension principles (see docbook customizing-cayenne-runtime.xml, "Contributing to Service Collections" section) : 

* in ServerModule declare 3 empty "service collections": 1. Default extended type - List<ExtendedType>; 2. User extended types - List<ExtendedType>; 3. Extended type factories - List<ExtendedTypeFactory> (assuming adapters don't customize the factories, we don't need to distinguish between user and default factories).
* Stop binding ExtendedTypeMap in DI (the service collections above will be bound; ExtendedTypeMap will be created inside DbAdapter, just like we are doing it now).. As a result we also won't need an interface/implementation split for the ExtendedTypeMap.
* Inject 3 service collections in adapters via constructor injection (no need for postInit())
* Created ExtendedTypeMap constructor that will not load default types by itself, but rather take 2 collections (types and factories) passed in constructor... Or simply have an empty constructor that does not load the default types, ad simply creates an empty map.
* Implement configuration merging logic in configureExtendedTypes() to go as this: 1. instantiate empty ExtendedTypesMap ; 2. Load default extended types; 3. load adapter specific extended types; 4. load user extended types; 5. Load factories. Essentially this is the same thing Dzmitry is doing in JdbcAdapter.postInit, only simpler, and based on service collections rather than a mutable ExtendedTypeMap.

Hope that makes sense...

> Improve custom ExtendedType registration API
> --------------------------------------------
>
>                 Key: CAY-1603
>                 URL: https://issues.apache.org/jira/browse/CAY-1603
>             Project: Cayenne
>          Issue Type: Improvement
>          Components: Core Library
>    Affects Versions: 3.1M2
>            Reporter: Dzmitry Kazimirchyk
>         Attachments: extended-types.patch
>
>
> Cayenne's present custom ExtendedTypes registration seems a little bit uncomfortable:
> // Find DataNode
> DataDomain domain = runtime.getDataDomain();
> // replace 'node_name' with the name of the DataNode you've entered in the Modeler.
> DataNode node = domain.getNode("node_name");
> // install ExtendedType
> node.getAdapter().getExtendedTypes().registerType(customType);
> It will be good to have some more friendly API, which allows custom type registration without getting DataNode and DataDomain. Suppose this can be implemented with a help of DI.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira