Introduction to System.Data.Bindings and Gtk.DataBindings >>
Introduction into System.Data.Bindings and Gtk#DataBindings


Even before introduction, just let me mention one fact. Mastering data bindings is a matter of hours. No one needs to learn anything what he wouldn't already know. As long as he has enough knowledge to use INotifyPropertyChanged, can design form and write a simple string. Every single bit of System.Data.Bindings has been carefully designed to not impose one single new thing on coder.

Before even begining getting into core of databindings, one must first understand reasons why he would need them. Take for example simple cell phone. Cell phone rings whenever someone calls you. Try to imagine cell phone without ringing and vibration... One would constantly have to look at his cell phone otherwise he wouldn't know if someone calls him or not. Everything is made much easier by introducing simple ring or vibration. You don't need to watch your phone, your phone simply notifies you when you need to watch it.  But now lets take cell phone example further.

- it is small so you can carry your phone around with your self without even noticing that
- you can store or read information from cell phone without needing to check if this is phone or not
- when someone calls you, your cell phone notifies you about that fact
- when you need to call someone, you simply pick up the phone and call that person
*** same things can be translated into delegates and methods of your class

Although simple cell phone has many more functions, these few will be enough to explain basic functionality of data binding.

While that simple cell phone is more than adequate for average person with generic needs... Imagine your self as CEO of fortune 500 company. Last thing you need is having all company calls routed trough your phone. You only want personalized and even those filtered out by someone like your personal secretary. Competent secretary will simply solve what it can be solved, reschedule what it needs to be rescheduled, write notification for things which are not urgent and route important phone calls to your cell phone imidietly. Even calling people probably gets routed trough your secretary unless they are personal as you don't want to wait for people to be available or you don't want to search for their phone numbers. And same kind of delegation is probably used for all tasks in case of that CEO. This is why there are different departments in a company like that. If this wouldn't be like that, then you as CEO suddenly become part of every department and you're more than probably unable to focus on one single thing.

Like people in mentioned company or cogs in machine, databinding provides exactly the same thing. Except most people are probably wondering here why would they need databinding when methods and delegated events already exist.  Well, CEO can't be part of every department in his company, so why put the same impossible strain on people who code software? The more complicated his software is, the more complex its workings are. And the fact that he has to know exatcly what his software does in every moment is not sparing any strains either. This is only needed when one is coding realtime application which probably accounts for less than 1%.

And databinding does exactly that. Provides one to code and forget. If he is interested in some events he will be notified exactly where it is needed and with exact information who and what as it was specified inside his code.

When MVC was introduced, biggest and the only important thing that was promised was separation of data and gui and exactly this promise is broken in every single implementation. Benefits of this promise are enormous. Really small and well separated self sufficient sotware parts. The smaller and more self sufficient they are the more maintainable your software is.

So... why basic delegates and methods are not enough? Simply because they still don't provide you with possibility of easy plugging into software without knowing its innards? Because you still have to know every single part? And make any kind of generic and external communication almost impossible? Make plugins so much harder to write? Make so much more strain needed for one to get into some project which has not been written by him?

And these are exactly the problems completely solved by System.Data.Bindings. Gtk#DataBindings are nothing but one cog which is using them and act as part of whole. Writing adaptors which provide specific functionality is just a matter of plugging into well formed engine.

All right... But before manual begins, one thing is important... "Separation of data and gui". This means that "How do I put my data into my form?" is simply a question which should not be asked now. One first has to learn how to walk to be able to learn how to run. That or work incorrectly with this engine.

But while learning how to walk is a matter of few hours, learning how to run will be matter of minutes. That is not a blind promise but rather well tested feature instead. You probably know how to design some form. Setting 2 or 3 properties? Piece of cake. Learning how to write mapping string? As simple as learning API of one single method, with the difference that mappings are written as string. But most importantly, by not skipping the base lessons you will learn how to make self sufficient software with perfectly separated small parts.

Q&A Personal notes for introduction
Q) Why reinventing new data binding stack?
A) For more reasons... but let me first tell you one fact... I am completely AGAINST reinventing the wheel, I always try to find FOSS solution before doing that. If I find one, I try to build on it. But FOSS databinding solution pluggable in Gtk simply didn't exist

1) First and most imporatant reason is the fact I'm listening the same fraze "FOSS doesn't know how to invent anything, FOSS just copies" for more than 12 years now, so I created complete data binding stack which is completely based on my personal code and design except maybe 300 lines (which were copied out of other FOSS or provided as they are). Complete project consist out of 250000 lines
2) The more I watched other data binding frameworks, the more I saw flaws they present with their design. And the fact that they all break the rule no.1 of MVC (code separation for data and form) is no helper either. Main guiding rule for me to create data binding was simply complete abstraction of data. If you follow this book and its examples one thing will be clear. GUI doesn't ever need to be referenced to data. The only common point of their existance is being referenced by dependancies of main assembly. Just as I always code my applications with "being pleasant and easy to use as much as possible" same rule was applied to my databinding code stack, except... user here is developer instead of end user.
3) Every single data binding requires one to study complex book and even more complex class hierarchy. And achieving exact opposite was my design guideline. Beside few methods, few completely basic classes (most of which are just incarnations of classes everyone already knows) and knowing how to write mapping string (which is as simple as one command with few parameters in .Net) there is no strain to coder. All users following my guidelines practically mastered whole thing in 5-10 hours. And since I can't personalize my time to teach everyone... well, this is why this book is being written
4) Has to be highly pluggable... Nicest example is Gtk.DataBindings. Gtk.DataBindings is NOT data binding solution but rather plugin to System.Data.Bindings. Plugin concept enables it to handle everything "Gtk way" and takes out every single strain away from developer. You don't care if you use zillion threads, there is no need for Application.Invoke and more... you don't even care if your thread is blockable or not. You don't care about the fact if you provide same classes to TreeView, SDB simply makes it compatible as much as it can. And list could go on and on

Q) Why even write data binding?
A) Well, my first MVC kind of data binding solution was written in '94 in freepascal. Even then, I was a real sucker for providing self aware desktop software. That stack never saw the light of the day although I think I could still find it somewhere. Reason why it simply got burried in pile of junk was simple. My love/hate relationship with pascal, I created patch for freepascal which was completely addin preprocessor feature which was only in effect if enabled with conditional directive or automatically if unit started with definitions as specified in preprocessor. Patch enabled interface multiple inheritance, code templating, template classes, inclusion classes, got rid of need for Interface/Implementation and with that enabled same kind of class writing like .Net (code inside class declaration), turn on/off relaxed synthax in the middle of the method, provided per class type and per reference and per property method connectable triggers, type descriptions (something like attributes, but less advanced), even more advanced properties than anything else (.Net only has get and set, with mine one can easily create whole stack of trigger events). The only trouble with my patch was introducing it. It didn't even matter if patch didn't break anything, I still constantly got 2 repeated answers "Borland won't do that" and "This will break"... No one even tried to compile anything ever. Which is kinda sad... I tried every source example I found to be really sure I didn't break anything, even freepascal it self. Everything worked and not even one single thing was broken. Patch only provided additions which were turned off by default... but since god Borland didn't come up with that... no way. No wonder FOSS is not getting more respect. Blindly following commercial solutions without one single try to improve things.

So I left "Fellowship of Borland" looking for something which would enable me to do my things and simply avoided coding anything until I find one language which is "has to run equally anywhere, readable, well structured, has everything I need by default". So, finally came .Net, and it was like a god send (ok,... I terribly miss template classes, inclusion classes and my flexible properties with trigger definition, but it is simply near enough). After almost 10 years of zero lines produced, I started coding again and even more... I enjoyed it.

So I was again facing decision... Find a free stack which is cross platform and works well. Qt was out of question (commercial), anything else was more or less morbidly supported. Winforms were out of question with less than adequate Linux performance (comparing it to same application on Windows. Running Winforms on Ms.Net or running it with Mono on Linux. Simply incomparable. Don't know the state of it now, it simply falls in "AVOID: blindly following other closed implementation" category). Which led to obvious choice of Gtk-sharp (which I loved even before for its container based approach). Except,... writing self aware software is not really sensible if you don't have data binding and even if it would have I would still probably wanted to work on free stack instead of closed solution which is just tracking original... So... here is your answer.

Q) Doesn't Mono fall into "AVOID: blindly following other closed implementation" category?
A) No, at least I don't feel like it. Mono and Gtk namespace are not implemented in Ms.Net. Which shows their intentions on doing it them selves in their own way. Beside the fact there is a big difference between CLR and API following. As I said... I waited 10 years for something to pop up which has at least basic features I need ALREADY covered, which means at least those basic features are already present in current CLR

Q) Why do you write if ((A == true) || (B == false)) if you could simply write if (A || !B)?
A) Simply... I want my conditions to be clear and readable even after I forget why I wrote that (and higher the number of conditions there is, the more unreadable shorthand becomes). I really hate when I need to figure out meaning of condition when people don't even use basic (). This is my personal quirk, but I like it like it is. Ohh,... I got a lot of those;)


INotifyPropertyChanged, BaseNotifyPropertyChanged and Notificator >>