<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 19, 2015, at 2:57 PM, Johnny Verhaeg <<a href="mailto:verhaeg@icloud.com" class="">verhaeg@icloud.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Would the data formats that the user may create on their own in the camel config be queriable and have normal text names, like CSV? If so, wouldn’t it be better just to add those to the existing list of formats (i.e., Java, XSD, CSV, etc.), then use the existing path fields to select the model? </div></div></div></blockquote><div><br class=""></div><div>Good question and not necessarily, but there is promise here. Two things need to happen when configuring the source/target for non-Java types:</div><div><br class=""></div><div>1) The Camel data format needs to be configured.</div><div>2) The model classes need to be generated.</div><div><br class=""></div><div>One immediate gotcha here is that the potential list of types supported by data formats is unbounded - a user can create their own data format to handle any type of custom/proprietary/unique data. This means we will always have to have an “Other” category.</div><div><br class=""></div><div>Another gotcha is what if a file extension is not a deterministic factor in selecting a data format, e.g. the delimiters for a variable length data format are specified in a .xml file? By asking the user on page 1 what type of data we are dealing with, we have the possibility to customize the source/target pages and just focus on the requirements for that type. IOW, I think we will likely move away from trying to guess the type based on the file extension and instead ask the type first and then customize the configuration page in the wizard for that type.</div><div><br class=""></div><div>The promise I mentioned earlier is that it would be nice for our own purposes if there was a standard way to plug new “configurators” in for types as we add them (e.g. CSV). Makes things faster for us and potentially allows a user to declare an extension which can configure their own custom formats.</div><div><br class=""></div><div>BTW, moving to a wizard where there’s a dedicated page will help in cases where the configuration of the data format requires more user input; the ones we have today are very simple because all questions can be answered using the schema or instance doc.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> I’m assuming that anytime the data type calls for a model, i.e., Java, CSV, etc., that the browser buttons for the path fields would restrict the available selections to classes on the class path.</div></div></div></blockquote><div><br class=""></div><div>Exactly!</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">BTW, I like the idea of making the source and target fields horizontally next to each other.</div></div></div></blockquote><div><br class=""></div><div>Makes sense, I stole it from you. :-) I like the way the mapping operations are displayed today and I thought this would be consistent with that. </div><div><br class=""></div><div>cheers,</div><div>keith</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 19, 2015, at 1:49 PM, Keith Babo <<a href="mailto:kbabo@redhat.com" class="">kbabo@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The reason of the extra pages is that we already ask for eight pieces of information from the user on a single page of the wizard and issue 151 would add four more, which is a bit crowded for a single page, IMO. Of course, this has to be balanced against the annoyance of multi-page wizards in general, but I think it’s a favorable tradeoff.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 19, 2015, at 1:57 PM, Johnny Verhaeg <<a href="mailto:verhaeg@icloud.com" class="">verhaeg@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">We’d already agreed to make the paths for both source and target required in the wizard, so I have no problem with removing the “change” ability from the editor. Not sure if I see the advantage of the extra pages, but maybe Brian’s mockups with shed light on that.<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 19, 2015, at 12:36 PM, Keith Babo <<a href="mailto:kbabo@redhat.com" class="">kbabo@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 19, 2015, at 1:23 PM, John Verhaeg <<a href="mailto:verhaeg@icloud.com" class="">verhaeg@icloud.com</a>> wrote:</div><div class=""><div 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=""><br class=""></div><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="">I'm probably missing something, but if the user doesn't select the path for Java types, what do we show in the editor in the model viewers?</span></div></blockquote><div class=""><br class=""></div><div class="">My initial thought was that they could just select it from the mapper, but after i thought about it some more I wrote the last bit of my email about selecting the Java type in the wizard.</div><br class=""><blockquote type="cite" class=""><div class=""><div 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=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Another idea I’ve been playing around with is removing support for changing the source and target types in the editor and instead allowing the user to select the target type in the wizard. Since changing a source or target type invalidates all mappings anyway, I don’t think this is much of an inconvenience. It also makes life simpler as we won’t need to change the Camel config from within the mapper editor any longer to update source/target types. If we went ahead with this plan, then my comments above about skipping the source/target pages in the wizard would no longer apply. Instead, we would have a page where the user had a type browser where they selected the source and target type on each page.</div></div></div></div></blockquote><div class=""><br class=""></div>So if the user changes their mind about source and/or target, they just delete the existing transformation.xml before restarting the wizard?</div></div></blockquote><div class=""><br class=""></div><div class="">Sorry, I phrased the last part of my initial email bit poorly and conflated two things. I will break them up:</div><div class=""><br class=""></div><div class="">1) We should prompt for the model class in the new transformation wizard for Java source/target types.</div><div class="">2) If we do (1), we have an option to remove support for changing the type in the editor.</div><div class=""><br class=""></div><div class="">We should definitely do (1), in my opinion. (2) is optional - an advantage is that it removes the need to prompt for camel context location when opening a map directly from the project explorer.</div><div class=""><br class=""></div><div class="">regards,</div><div class="">keith</div></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>