To provide a bit of background here - data formats don’t come with the ability to generate
model classes on their own. That’s something we added for XML, XSD, JSON, and JSON schema
because it was relatively straightforward. As we move to other types (CSV is a good
example), it’s not quite as easy, so we will have to evaluate these on a case-by-case
basis. Ditto for the configuration of a data format. For JSON, we aren’t using any
non-default configuration at all right now. For JAXB, we are specifying one configuration
option (the context path). Contrast that with the options available for the CSV data
format <
http://camel.apache.org/csv.html>. The UI will likely need to provide a lot
more configuration visibility for something like CSV.
I mention this because other data formats won’t just be a matter of selecting a type and
pointing at a file - there’s more to it than that. That’s why this first iteration is
just focused on allowing the user to define their own data format and generate their own
model classes. Then in our wizard we just ask them for the model class they want to use
along with the id of the data format.
hth,
keith
On Mar 19, 2015, at 5:52 PM, Keith Babo <kbabo(a)redhat.com>
wrote:
> On Mar 19, 2015, at 5:07 PM, Johnny Verhaeg <verhaeg(a)icloud.com
<mailto:verhaeg@icloud.com>> wrote
>
> Why are those gotchas? It still sounds like what I suggested about merging the
custom data formats with our known ones would still work and no extra fields would be
needed. What am I missing?
How would you know what custom data formats to merge ahead of time? Let’s say the user
creates a custom XYZDataFormat for a proprietary XYZ format that they use. There’s no way
for us to know about this format.
Even for existing data formats, the requirements may go beyond just pointing at a file,
especially if the file is an instance document and the configuration supplies details on
how that instance document is used to generate model classes and/or configure the data
format itself.
~ keith
_______________________________________________
jbosstools-fuse-dev mailing list
jbosstools-fuse-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-fuse-dev