10:07 p.m.
On Mar 19, 2015, at 2:55 PM, Keith Babo <kbabo(a)redhat.com>
wrote:
> On Mar 19, 2015, at 3:33 PM, Johnny Verhaeg <verhaeg(a)icloud.com> 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.
So given that, let me go back to your gotcha statements:
"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.
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."
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?