snip... > I think an interesting question to ask is: am I requiring that the > application/componentType databinding be split out into an > input/output introspection/calculation in my motivating use case. A > quick review makes me think the answer is 'no'. Maybe I'm not > thinking this through all the way yet, but if I'm right then we only > have to worry about a new granularity in configuring the binding > interface model.
Right, I think the binding interface model is the one we need to update. The component type should remain the same as we nee to transform to/from those types as specified. > > In the WF cases in which we bypass the DataTransformationInterceptor > today, I'm not sure if it's because of some non-trivial code which > would need to be written to do so or is it just because of convenience > (or performance?). I can see in > DataTransformationInterceptor.transform() that we already have a path > to do a no-op in case the two DataType(s) are equals(), so it seems > some part of the functionality must be there to let DTI do a no-op > rather than bypassing DTI altogether by not establishing it as an > interceptor on the chain. Not sure why it is as it is. I suppose it is a small performance optimization in missing out the interceptor altogether. Simon
