<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Ah, that helps a lot. Not clear at all where there'd be a hook in the tooling to allow for a programmatic setting, but I'll take your word for it. <br><br><br></div><div><br>On Mar 19, 2015, at 5:37 PM, Keith Babo <<a href="mailto:kbabo@redhat.com">kbabo@redhat.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class="">On Mar 19, 2015, at 4:52 PM, Keith Babo <<a href="mailto:kbabo@redhat.com" class="">kbabo@redhat.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 19, 2015, at 5:07 PM, Johnny Verhaeg <<a href="mailto:verhaeg@icloud.com" class="">verhaeg@icloud.com</a>> wrote</div><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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?</span></div></blockquote><br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div>I guess I thought the XYZDataFormat named would be already specified in the Camel configure, and thus queriable. Not so?</div></div></blockquote><div><br class=""></div><div>Ah, now I see where you are going with this line of thought. Would work in some cases, but there are cases where a data format can be registered programmatically, where this would not be the case. Still, I think this is an idea worth thinking about in addition to supporting “Other”.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">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.</div></div></blockquote><div class=""><br class=""></div>This seems way too ambitious to me. I thought you indicated the models would already have been generated in the custom case? </div></div></div></blockquote><div><br class=""></div><div>They will. I was talking about cases where we support a data format as a first-class citizen (like JSON, XML, XSD today). Concrete example: we don’t support CSV right now. At first, we will just support it via this “Other” type support. That means the user created the data format and generated the model classes ahead of time. In a future milestone, we will consider adding CSV support directly to our tooling. When we do that, we will add support for generating the models from the tooling (just for CSV) and configuring the data format.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">How could we possibly know how to generate models from within the wizard based upon completely data format-specific configuration that we'd have no idea how to interpret?</div></div></div></blockquote><div><br class=""></div><div>We wouldn’t. </div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">Or are you envisioning specific types of custom configuration to support?</div></div></div></blockquote><div><br class=""></div><div>Yep, this. I think we just crossed wires on the above. We generate models and provide specific configuration options for the data types we directly support. For the “other” type, we assume the model classes are already available and the user has created the data format configuration already. All we do in our tooling is point to an existing class and data format id.</div><div><br class=""></div><div>regards,</div><div>keith</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">~ keith</div><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></blockquote></body></html>