On Mar 19, 2015, at 1:23 PM, John Verhaeg <verhaeg(a)icloud.com&gt; wrote: 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?

> > 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. So if the user changes their mind about source and/or target, they just delete the existing transformation.xml before restarting the wizard?

On Mar 19, 2015, at 1:57 PM, Johnny Verhaeg <verhaeg(a)icloud.com&gt; wrote: 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. > On Mar 19, 2015, at 12:36 PM, Keith Babo <kbabo(a)redhat.com <mailto:kbabo@redhat.com>> wrote: > > >> On Mar 19, 2015, at 1:23 PM, John Verhaeg <verhaeg(a)icloud.com <mailto:verhaeg@icloud.com>> wrote: >> >> 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? > > 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. > >> >>> >>> 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. >> >> So if the user changes their mind about source and/or target, they just delete the existing transformation.xml before restarting the wizard? > > Sorry, I phrased the last part of my initial email bit poorly and conflated two things. I will break them up: > > 1) We should prompt for the model class in the new transformation wizard for Java source/target types. > 2) If we do (1), we have an option to remove support for changing the type in the editor. > > 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. > > regards, > keith

On Mar 19, 2015, at 2:57 PM, Johnny Verhaeg <verhaeg(a)icloud.com&gt; wrote: 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?

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.

BTW, I like the idea of making the source and target fields horizontally next to each other.

> On Mar 19, 2015, at 1:49 PM, Keith Babo <kbabo(a)redhat.com <mailto:kbabo@redhat.com>> wrote: > > 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. > > >> On Mar 19, 2015, at 1:57 PM, Johnny Verhaeg <verhaeg(a)icloud.com <mailto:verhaeg@icloud.com>> wrote: >> >> 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. >> >>> On Mar 19, 2015, at 12:36 PM, Keith Babo <kbabo(a)redhat.com <mailto:kbabo@redhat.com>> wrote: >>> >>> >>>> On Mar 19, 2015, at 1:23 PM, John Verhaeg <verhaeg(a)icloud.com <mailto:verhaeg@icloud.com>> wrote: >>>> >>>> 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? >>> >>> 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. >>> >>>> >>>>> >>>>> 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. >>>> >>>> So if the user changes their mind about source and/or target, they just delete the existing transformation.xml before restarting the wizard? >>> >>> Sorry, I phrased the last part of my initial email bit poorly and conflated two things. I will break them up: >>> >>> 1) We should prompt for the model class in the new transformation wizard for Java source/target types. >>> 2) If we do (1), we have an option to remove support for changing the type in the editor. >>> >>> 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. >>> >>> regards, >>> keith >> >

On Mar 19, 2015, at 3:33 PM, Johnny Verhaeg <verhaeg(a)icloud.com&gt; wrote: > 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. I guess I’m still a little confused about where and when some of this occurs. Wouldn’t the user need to define the custom Camel data format and generate the associated model classes before they specify/select it in our wizard?

> 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. This makes sense to me, too. Sounds like maybe this means we should move the type field “before" the path field at a minimum, regardless of whether that means “above” on the same page, or by itself on the first page with the path fields on following pages.

If they end up on the same page after all this, I would still attempt to auto-select the type if the user happens to choose the path first, but that’s just a little extra candy.

> 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. > > 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. I’m certainly not against having multiple pages in the wizard in general, assuming something calls for that (including just busyness). I’m just trying to make sure we’re really at that point right now.

On Mar 19, 2015, at 4:23 PM, Brian Fitzpatrick <bfitzpat(a)redhat.com&gt; wrote: I've put together a quick mockup of some screens for the "Java to Java" case... Let me know how close I am... _______________________________ Brian Fitzpatrick (aka "Fitz") Senior Software Engineer, Tooling JBoss by Red Hat ----- Original Message ----- From: "Keith Babo" <kbabo(a)redhat.com&gt; To: "Johnny Verhaeg" <verhaeg(a)icloud.com&gt; Cc: jbosstools-fuse-dev(a)lists.jboss.org Sent: Thursday, March 19, 2015 1:55:21 PM Subject: Re: [jbosstools-fuse-dev] [jbosstools-fuse-dev - 4] new transformation wizard > On Mar 19, 2015, at 3:33 PM, Johnny Verhaeg <verhaeg(a)icloud.com&gt; wrote: >> 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. > > I guess I’m still a little confused about where and when some of this occurs. Wouldn’t the user need to define the custom Camel data format and generate the associated model classes before they specify/select it in our wizard? In the case of “Other”, yes, that’s exactly what they would do. > >> 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. > > This makes sense to me, too. Sounds like maybe this means we should move the type field “before" the path field at a minimum, regardless of whether that means “above” on the same page, or by itself on the first page with the path fields on following pages. With the proposed change, the type is on the first page in the [Source Type] —> [Target Type] row. Those would be drop-downs like we have today. The path would no longer be on the first page and would be configuration that is entered on the following pages. > If they end up on the same page after all this, I would still attempt to auto-select the type if the user happens to choose the path first, but that’s just a little extra candy. True, but I think they should be on separate pages. > >> 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. >> >> 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. > > I’m certainly not against having multiple pages in the wizard in general, assuming something calls for that (including just busyness). I’m just trying to make sure we’re really at that point right now. > Discussing this has already produced more ideas, so continue to fire away with questions/ideas! ~ keith _______________________________________________ jbosstools-fuse-dev mailing list jbosstools-fuse-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-fuse-dev <New Fuse Transformer Wizard.pdf>

On Mar 19, 2015, at 7:37 PM, John Verhaeg <verhaeg(a)icloud.com&gt; wrote: This demonstrates what the current data formats would look like, but for "other" there'd also be an additional text field for the data format, right? > On Mar 19, 2015, at 3:23 PM, Brian Fitzpatrick <bfitzpat(a)redhat.com <mailto:bfitzpat@redhat.com>> wrote: > > I've put together a quick mockup of some screens for the "Java to Java" case... > > Let me know how close I am... > > _______________________________ > Brian Fitzpatrick (aka "Fitz") > Senior Software Engineer, Tooling > JBoss by Red Hat > > ----- Original Message ----- > From: "Keith Babo" <kbabo(a)redhat.com&gt; > To: "Johnny Verhaeg" <verhaeg(a)icloud.com&gt; > Cc: jbosstools-fuse-dev(a)lists.jboss.org > Sent: Thursday, March 19, 2015 1:55:21 PM > Subject: Re: [jbosstools-fuse-dev] [jbosstools-fuse-dev - 4] new transformation wizard > > >>> On Mar 19, 2015, at 3:33 PM, Johnny Verhaeg <verhaeg(a)icloud.com&gt; wrote: >>> 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. >> >> I guess I’m still a little confused about where and when some of this occurs. Wouldn’t the user need to define the custom Camel data format and generate the associated model classes before they specify/select it in our wizard? > > In the case of “Other”, yes, that’s exactly what they would do. > >> >>> 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. >> >> This makes sense to me, too. Sounds like maybe this means we should move the type field “before" the path field at a minimum, regardless of whether that means “above” on the same page, or by itself on the first page with the path fields on following pages. > > With the proposed change, the type is on the first page in the [Source Type] —> [Target Type] row. Those would be drop-downs like we have today. The path would no longer be on the first page and would be configuration that is entered on the following pages. > >> If they end up on the same page after all this, I would still attempt to auto-select the type if the user happens to choose the path first, but that’s just a little extra candy. > > True, but I think they should be on separate pages. > >> >>> 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. >>> >>> 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. >> >> I’m certainly not against having multiple pages in the wizard in general, assuming something calls for that (including just busyness). I’m just trying to make sure we’re really at that point right now. > > Discussing this has already produced more ideas, so continue to fire away with questions/ideas! > > ~ keith > > > > _______________________________________________ > jbosstools-fuse-dev mailing list > jbosstools-fuse-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-fuse-dev > <New Fuse Transformer Wizard.pdf>

On Mar 19, 2015, at 7:37 PM, John Verhaeg <verhaeg(a)icloud.com&gt; wrote: This demonstrates what the current data formats would look like, but for "other" there'd also be an additional text field for the data format, right? > On Mar 19, 2015, at 3:23 PM, Brian Fitzpatrick <bfitzpat(a)redhat.com <mailto:bfitzpat@redhat.com>> wrote: > > I've put together a quick mockup of some screens for the "Java to Java" case... > > Let me know how close I am... > > _______________________________ > Brian Fitzpatrick (aka "Fitz") > Senior Software Engineer, Tooling > JBoss by Red Hat > > ----- Original Message ----- > From: "Keith Babo" <kbabo(a)redhat.com&gt; > To: "Johnny Verhaeg" <verhaeg(a)icloud.com&gt; > Cc: jbosstools-fuse-dev(a)lists.jboss.org > Sent: Thursday, March 19, 2015 1:55:21 PM > Subject: Re: [jbosstools-fuse-dev] [jbosstools-fuse-dev - 4] new transformation wizard > > >>> On Mar 19, 2015, at 3:33 PM, Johnny Verhaeg <verhaeg(a)icloud.com&gt; wrote: >>> 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. >> >> I guess I’m still a little confused about where and when some of this occurs. Wouldn’t the user need to define the custom Camel data format and generate the associated model classes before they specify/select it in our wizard? > > In the case of “Other”, yes, that’s exactly what they would do. > >> >>> 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. >> >> This makes sense to me, too. Sounds like maybe this means we should move the type field “before" the path field at a minimum, regardless of whether that means “above” on the same page, or by itself on the first page with the path fields on following pages. > > With the proposed change, the type is on the first page in the [Source Type] —> [Target Type] row. Those would be drop-downs like we have today. The path would no longer be on the first page and would be configuration that is entered on the following pages. > >> If they end up on the same page after all this, I would still attempt to auto-select the type if the user happens to choose the path first, but that’s just a little extra candy. > > True, but I think they should be on separate pages. > >> >>> 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. >>> >>> 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. >> >> I’m certainly not against having multiple pages in the wizard in general, assuming something calls for that (including just busyness). I’m just trying to make sure we’re really at that point right now. > > Discussing this has already produced more ideas, so continue to fire away with questions/ideas! > > ~ keith > > > > _______________________________________________ > jbosstools-fuse-dev mailing list > jbosstools-fuse-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-fuse-dev > <New Fuse Transformer Wizard.pdf>

On Mar 19, 2015, at 5:07 PM, Johnny Verhaeg <verhaeg(a)icloud.com&gt; 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?

On Mar 19, 2015, at 4:52 PM, Keith Babo <kbabo(a)redhat.com&gt; wrote: > On Mar 19, 2015, at 5:07 PM, Johnny Verhaeg <verhaeg(a)icloud.com&gt; 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

On Mar 19, 2015, at 5:37 PM, Keith Babo <kbabo(a)redhat.com&gt; wrote: > >> On Mar 19, 2015, at 4:52 PM, Keith Babo <kbabo(a)redhat.com&gt; wrote: >> >> >>> On Mar 19, 2015, at 5:07 PM, Johnny Verhaeg <verhaeg(a)icloud.com&gt; 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. > > I guess I thought the XYZDataFormat named would be already specified in the Camel configure, and thus queriable. Not so? 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”. > >> 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. > > This seems way too ambitious to me. I thought you indicated the models would already have been generated in the custom case? 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. > 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? We wouldn’t. > Or are you envisioning specific types of custom configuration to support? 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. regards, keith > >> >> ~ keith