Okay, question then:
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>
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
>