cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrus Adamchik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAY-1603) Improve custom ExtendedType registration API
Date Mon, 29 Aug 2011 21:47:37 GMT

    [ 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

        

Mime
View raw message