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

[Johnny Verhaeg]

> On Mar 19, 2015, at 2:20 PM, Keith Babo <kbabo at redhat.com> wrote:
> 
> Good question and not necessarily, but there is promise here.  Two things need to happen when configuring the source/target for non-Java types:
> 
> 1) The Camel data format needs to be configured.
> 2) The model classes need to be generated.
> 
> 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.