You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Andrus Adamchik (JIRA)" <ji...@apache.org> on 2015/10/12 17:07:05 UTC

[jira] [Updated] (CAY-2029) Allow out-of-order insertion into DI lists

     [ 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)