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] [Updated] (CAY-2029) Allow out-of-order insertion into DI lists
Date Mon, 12 Oct 2015 15:07:05 GMT

     [ https://issues.apache.org/jira/browse/CAY-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrus Adamchik updated CAY-2029:
---------------------------------
    Description: 
We need that per CAY-2028. The following API is suggested:

{noformat}
// binding a type. Key is implicit, as it can be calculated automatically
ListBuilder.add(Class<T> type);

// binding an instance. Key is implicit and is calculated automatically. 
// It can not be transparently addressed in ordering
ListBuilder.add(T object);

// @since 4.0
// binding an instance. Key is explicit can be addressed when inserting other items
ListBuilder.add(Key<T> key, T object);
{noformat}

All 3 styles of binding should return a subclass of ListBuilder that supports reordering of
the previously inserted item:

{noformat}
ListBuilder after(Class<?> type);
ListBuilder after(Key<?> key);
ListBuilder before(Class<?> type);
ListBuilder before(Key<?> key);
{noformat}

Some implementation points:

* If no before/after is specified, the ordering is non-deterministic.
* The algorithm should detect cycles (key1 before key2 and key2 before key1) and throw an
exception
* The algorithm should allow to reference another key in before/after, prior to that key being
bound to DI.

The reason for using this elaborate mechanism, instead of letting the caller to inspect the
contents of the list directly is that the DI list contains mostly Providers, usually multiple
Providers wrapping each other. So looking at that directly makes little sense.



  was:
We need that per CAY-2028. The API might look like this:

{noformat}
ListBuilder.add(label, object).after(label1);
ListBuilder.add(label, object).before(label2);
{noformat}

So each item can optionally have a String label. If no label is used on insertion (existing
API), the label can be generated semi-randomly. Then later the label can be used to refer
to a position in the list without knowing the position, just to specify relative ordering.


The reason for using String labels instead of letting the caller to inspect the contents of
the list directly is that the DI list contains mostly Providers, usually multiple Providers
wrapping each other. So looking at that directly makes little sense.




> Allow out-of-order insertion into DI lists
> ------------------------------------------
>
>                 Key: CAY-2029
>                 URL: https://issues.apache.org/jira/browse/CAY-2029
>             Project: Cayenne
>          Issue Type: Task
>            Reporter: Andrus Adamchik
>            Assignee: Savva Kolbachev
>
> We need that per CAY-2028. The following API is suggested:
> {noformat}
> // binding a type. Key is implicit, as it can be calculated automatically
> ListBuilder.add(Class<T> type);
> // binding an instance. Key is implicit and is calculated automatically. 
> // It can not be transparently addressed in ordering
> ListBuilder.add(T object);
> // @since 4.0
> // binding an instance. Key is explicit can be addressed when inserting other items
> ListBuilder.add(Key<T> key, T object);
> {noformat}
> All 3 styles of binding should return a subclass of ListBuilder that supports reordering
of the previously inserted item:
> {noformat}
> ListBuilder after(Class<?> type);
> ListBuilder after(Key<?> key);
> ListBuilder before(Class<?> type);
> ListBuilder before(Key<?> key);
> {noformat}
> Some implementation points:
> * If no before/after is specified, the ordering is non-deterministic.
> * The algorithm should detect cycles (key1 before key2 and key2 before key1) and throw
an exception
> * The algorithm should allow to reference another key in before/after, prior to that
key being bound to DI.
> The reason for using this elaborate mechanism, instead of letting the caller to inspect
the contents of the list directly is that the DI list contains mostly Providers, usually multiple
Providers wrapping each other. So looking at that directly makes little sense.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message