You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Charles Moulliard (JIRA)" <ji...@apache.org> on 2013/04/30 08:40:20 UTC

[jira] [Commented] (CAMEL-3496) camel-bindy - Make it easier to use by getting rid of List structure and other improvemets

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

Charles Moulliard commented on CAMEL-3496:
------------------------------------------

1)
The bindy API is unfortunately a bit cumbersome because it stores its result in a List<Map<String, Object>> structure. 
Instead it should store the object directly in the List<Object>
End users would expect this instead of the cumbersome API.

>> I know that when I have created camel-bindy and decided to use List<Map<String, Object>>, the choice to adopt this structure was not evident and will complicate data extraction, ... Anyway, I don't thing that replacing it by List<Object> is also the solution as the model could contain several objects of different types (e.g. List(Order, Person, Record, ...) 

2)
Also the marshal and unmarshal operators should take an optional class name so you know which class to use in case you use a package which has other @CsvRecord classes in the same package. Then you can tell Camel to use this class in case of ambiguity.

>> Can you provide an example as I don't really see the advantage / added value of that ? 

3)
And if you use multiple objects for one @Record we should introduce an option on the @Record to mark the class as the top class (the starting class).

>> As we also have Footer, Header or Trailer classes for FixedLengthDataFormat, we should certainly find a more general mechanism to define if a class is top/trailer or header/core/footer

                
> camel-bindy - Make it easier to use by getting rid of List<Map> structure and other improvemets
> -----------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-3496
>                 URL: https://issues.apache.org/jira/browse/CAMEL-3496
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-bindy
>    Affects Versions: 2.5.0
>            Reporter: Claus Ibsen
>            Assignee: Rich Newcomb
>             Fix For: 3.0.0
>
>
> 1)
> The bindy API is unfortunately a bit cumbersome because it stores its result in a {{List<Map<String, Object>>}} structure. 
> Instead it should store the object directly in the {{List<Object>}}
> End users would expect this instead of the cumbersome API.
> 2)
> Also the marshal and unmarshal operators should take an optional class name so you know which class to use in case you use a package which has other @CsvRecord classes in the same package. Then you can tell Camel to use this class in case of ambiguity.
> 3)
> And if you use multiple objects for one @Record we should introduce an option on the @Record to mark the class as the *top* class (the starting class).
> 4)
> And the source code could use a bit of love here and there, and most likely add more checks and throw better exceptions so end users better understand what would be wrong.
> This will break backwards comp. so let's try to do this for Camel 3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira