<< Adaptors - basics Adaptors - basics >>
Chapter 4
Adaptors - Advanced


NOTICE!
Read this chapter only if you wanna tweak functionality (and you can really benefit out of this) or you really need something else. Complete basic usage does not involve any need to read this chapter! People not who don't plan to tweak System.Data.Bindings should simply skip this chapter

Last thing important to know about adaptor is how to tweak them. By tweaking adaptors whole things starts really being written directly on your skin. Probably best example of tweaking is MappedAdaptor. Mapped adaptor simply registers to object pointed by named property and presents that one as his FinalTarget. As simple as that.

And examples? Well... like first I intentionally won't provide anything else but steps. People reading this chapter should get their hands dirty them selves since practice is best way to learn

Implementing ComplexMappedAdaptor

Overriding Mappings and Disconnect(). Both are virtual. Mappings simply specifies mapped destination and Disconnect()... well, disconnects.

Well, one thing I intentionally didn't create as I don't know if I like the principle of that approach or not. But as example of this topic it really is the nicest thing, sometimes I even wonder if this last is not the reason I don't want to implement it.

Creating adaptor that would handle "Manager.PersonalInformation.Address.CityInformation" kind of mapping is the easiest thing ever.
step 1) Split string by "." in overriden set { } of Mappings (Mappings is virtual property) and be careful to call base.Mappings = firststring
step 2) For each string except first in result create new MappedAdaptor (string_part) or reuse already created
step 3) Point new adaptor to previous
step 4) Take care of adaptors in Disconnect() by simply calling Disconnect() on each one
step 5) You are done and officialy written first Adaptor which perfectly handles mapping chain

The only important thing is to keep track of created adaptors on Mappings change. You must disconnect them to unlink old chain.

Note, CityInformation is object reference as Adaptors map to references not values

Now... what exactly is happening there in your new adaptor. Whenever Mappings change you provide chain of new mapping Adaptors. Which automatically leads to the fact that whenever anyone in chain is changed adaptor customers will get their feedback if result means that final link in chain has changed.

Implementing enum/string based adaptor with DoGetFinalTarget()

Overriding DoGetFinalTarget() - This methods result is simply presented as FinalTarget. If you provide different resolving. Whole lotta things can happen'.

step 1) declare enum (or array of strings, whatever you think it will be more usable)
step 2) override DoGetFinalTarget and simply use if else/switch {} to resolve value and point to different reference or adaptor for each value
step 3) you are done

Well. this Adaptor might not seem usefull at first,... until you join it with something like attributes on enum fields or namespace names resolved with Reflection. This way you could resolve additional information on the fly instead of resolving it with specialized adaptor classes.

So... what happened here? Whenever you pass enum or string as target to your new Adaptor class, he simply wants to follow his chain. But since you redirected chain into resolving of different references which are probably not connected to enum or string, those exact references become your final targets. And again, whenever that target changes... adaptor customers get notified

Conclusion

This actually concludes Advanced part. I mostly consider it advanced only for one reason. People tend always to enforce harder way, not even looking at different possibilities.
<< Adaptors - basics Adaptors - basics >>
Chapter 4
Adaptors - Advanced