Re: [jbosstools-fuse-dev] [jbosstools-fuse-dev - 4] new transformation wizard

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>