Saturday, February 25, 2012

Custom Component development questions

I have looked at everything I could find on custom components, and I'm still confused about what has to be implemented in ReinitializeMetadata. The first custom component I'm trying to build is very similar to the Audit component, a derived column synchronous transformation that should be able to create any non-empty subset of four types of output columns.

I haven't found anything that does much with the inputs, the samples all seem to rely on RemoveInvalidInputColumns. I haven't found any substantial explanation of what this method actually does, or whether there are cases it doesn't handle. If it really handles all problems on the input side I don't need to know the details, but I'd like to hear some confirmation that this is the case.

For outputs, most of the sample projects seem to just call the base method. Some projects throw out all the output columns and create new ones to match the input columns one-to-one. Project Real throws away all the output columns and external metadata columns and creates a standard set of output columns with external metadata. The RegEx sample project uses information in a component custom property to tell it what output columns to expect, then adds missing columns and deletes unwanted columns. All of these approaches are using some reference information to inform it which outputs belong and which don't. What do you do when there is no other reference, just the output column and external metadata column collections?

The description for this method is "fix the errors found in Validate", but these projects just delete everything that wasn't perfect and recreate anything missing. In cases where the number and types of output columns require some user configuration, maybe a few custom properties, it seems a little high-handed to throw it all away and make them start from scratch. Or do you assume that this method isn't called unless the component state is really screwed up? It seems to me that simply adding or deleting input and output columns in the Advanced Editor would trigger ReinitializeMetadata because the external metadata would be out of sync. If it reacted by immediately re-adding an optional default column you deleted, or deleting an unconfigured column you just added, it would be pretty annoying.

Assuming that I wanted ReinitializeMetadata to actually fix things, I have some specific questions:

1 If an output column is not mapped to an external metadata column (or mapped to a nonexistent emc), should the output column be deleted or should a matching external column be created?

2 Same question reversed, if an external column is not mapped to any output column, should it be deleted or a matching output column created?

3 Would it make sense to look for compatible unmapped output and external columns and remap them?

4 If the user adds or deletes an output column in the advanced editor, was that an output column or an external metadata column?

And another thing, is there a definative list of which methods should be marked as not cls-compliant?

If your component is similar to Audit you do not need to worry about external columns, or input columns or ReinitializeMetadata.

All you need to do is to allow inserting output columns (implement InsertOutputColumn) and probably add a custom property to identify them. They can be added using the advanced editor.

You can look at the metadata of Audit transform in the advanced editor to get an idea.

|||

I asked for enlightenment, and a reply of "you do not need to worry about it" doesn't really help. If my next project is a more complicated component I'll need to worry about it, so I'm still trying to get a more fundamental understanding if the design-time behavior. I'm not optimistic enough to expect my first component project to work the first time, and to debug it I think I need to know more about what the base class does, what behavior I need to add to it, and what I should avoid doing to it.

My basic problem is that I don't feel the published documentation or available sample code give me a good general idea of what a fully-featured and robust implementation of a custom component should include.

I have looked at the Audit transform in the advanced editor, and it is very close to what I need (at least for outputs). One question that it answered was that changing the ouput column datatype as a side effect of a custom property change is apparently legal (I assume this is happening in SetOutputColumnProperty). It appears to have a custom editor UI for the custom property, but knowing that one exists doesn't help me build my own.

The Calendar sample project showed me everything I needed to know about creating a TypeConverter for my custom properties. I think a lot of my current questions would be answered if I could get sample code for the design-time behavior of the Audit component. Is there any chance of that happening?

|||

It is good to get feedback on specific gaps in the documentation - the docs team watch this forum very careful to plan their future content. So, while you won't see code for our stock components being shared, you may well see these issues addressed in future samples. Our documentation in 2005 is progressive and is being constantly refreshed.

Meanwhile, let's see if we can get you some answers to those questions - but do bear in mind that Bob was trying to help you with your specific needs to help you over a bump in developing your component, rather than giving a detailed advanced tutorial. Forums are great for the former, not so good for the latter.

Donald

|||

Unless you understand why you would need to use external metadata, and for normal transforms you do not, then these answers may not make sense, and certainly don't apply to an Audit style transform.

1 If an output column is not mapped to an external metadata column (or mapped to a nonexistent emc), should the output column be deleted or should a matching external column be created?

Delete the output column. This is an invalid state, and with correct coding of the component it should never happen. The best defense is to override all the input/output and column methods on the PipelineComponent class. Throw errors if people try and do something silly. Then only way left for someone to mess it up is via code as your UI and the Advanced Ui should both use the managed wrapper when manipulating columns etc.

2 Same question reversed, if an external column is not mapped to any output column, should it be deleted or a matching output column created?

It should be left alone really, although that depends on the component design. Normally you create the output column and map to "select" it. Not all external columns have to be selected, in most components at least, hence component design.

3 Would it make sense to look for compatible unmapped output and external columns and remap them?

You should look for invalid mappings and silly stuff in Validate, and return the needs new metadata status. If you then fix them in RMD, well that is up to you. What is you component supposed to do. Simple fixes I'd say go for it, but think how it may impact the user, and could it give new meaning to what they wanted originally? Saying that see answers for 1 and 2 first.

4 If the user adds or deletes an output column in the advanced editor, was that an output column or an external metadata column?

An output column.

And another thing, is there a definative list of which methods should be marked as not cls-compliant?

The compiler will warn you. Set true at the assembly level, then any methods which are non-compliant and not attributed as such will generate a warning, so easy enough to pick up and fix.

No comments:

Post a Comment