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

[John Verhaeg]

Ah, that helps a lot. Not clear at all where there'd be a hook in the tooling to allow for a programmatic setting, but I'll take your word for it. 



> On Mar 19, 2015, at 5:37 PM, Keith Babo <kbabo at redhat.com> wrote:
> 
>> 
>>> On Mar 19, 2015, at 4:52 PM, Keith Babo <kbabo at redhat.com> wrote:
>>> 
>>> 
>>>> On Mar 19, 2015, at 5:07 PM, Johnny Verhaeg <verhaeg at icloud.com> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-fuse-dev/attachments/20150319/b9dd074a/attachment.html