[
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
