So in my last post, I blogged about WPF components. I have veen deep with the ones I mentioned and more in the past 2 weeks and I have reached some conclusions about WPF component vendors. I have also eval’d more vendors out there to add to my list.

So last post, I was continuing to actively review:

• Infragragistics
• ComponentOne
• Developer Express
• Syncfusion

I was mainly looking @ their grids as my #1 needed component. I can say that I have spent a fair bit of time now with each one, and I have some solid opinions. I have also drilled down a level and reviewed the suites from other vendors including:

• Xceed
• Telerik
• DivElements
• and even Nukeation’s Reuxables reusable WPF themes

At the end of the day, there is actually a fair bit of usable vendor software out there. The grid was by far the hardest to select as there are just so many ‘bells and whistles’ you can have in a grid product.

My WPF Vendor Grid Rankings

1. Xceed
2. Infragistics
3. ComponentOne
4. DevExpress
5. Telerik
6. Syncfusion

That is not uber-precise, but it is my general feeling. Here is a random list of features I was looking for:

• performance
• summaries
• hierarchical data
• quality data-templating
• general ‘feel’ of the grid
• sorting
• skinning
• auto-filter
• any Excel-like features
• API feel
• out of the box embedded editors
• documentation/ examples

Other WPF components (excluding the grids)

That ranking is just for my grid. Interestingly, my least favorite grid implementation was Syncfusion’s, but they actually had the best (IMO) general controlls suite; The Syncfusion WPF Tools set. I compared this with Infragistics control suite for the most part. I did look at all the above mentioned vendors, and the ones in contention were mainly Syncfusion and Infragistics.

Infragistics seemed to focus on ‘bling’. They had really nice carousel controls, but financial apps are no place for those unfortunately. They had a few basic ‘editors’, but syncfusion just had a few more.

Docking and Ribbon control; both Syncfusion and Infragistics offered good Ribbon controls and Docking controls. They all look the same. The APIs are very similar (unsurprisingly). I liked them both.

Explorer bar; Infragistics latest CTP has an explorer bar, and Syncfusion has one out. Infragistics gave me some bugs while working with it, so I could not get too deep. It kept blowing out my XAML files unfortunately. I am sure it is just fine, once it is out of beta.

Syncfusion also has a handy Autocomplete control. It is not fantastic, but it was in use in minutes and I got good use of it fast. Infragistics has no analogy.

Syncfusion has the following controls:

• Ribbon
• Explorer bar
• Autocomplete
• Task bar
• Docking
• Font list/ combo box
• Gallery (cool)
• Datetime edit
• Numeric Up/ down
• Color Picker
• Advanced Tree View
• Clock
• Masked Text Box
• Integer Text Box
• Double Text Box
• Calendar Edit

I could go on and on. Essentially, this is what I have so far. I hope it is helpful to someone/ anyone!

-Chris-

Well, I have been building toy projects with WPF for some time now. I have been monitoring and trying Acropolis, Prisim and whatever the heck they call prism now. I have been closely monitoring the landscape of 3rd party vendors.

In order to be productive and deliver real, purposeful applications I need to be able to focus on the business domain (finance/ trading in my case). I DO NOT want to build low level widgets. I do not want to rebuild the wheel. In order to do this, I need to use a component vendor. This gives your application ‘perceived integrity’ inasmuch as your users will see something and touch something that looks like a modern application, not a 1995 web page with java applets and midi songs.

So - I have been following the big vendors and their WPF offerings:

* Infragistics
* Syncfusion
* ComponentOne
* Developer Express

I have ben waiting for Developer Express in particular to come out with their grid offering. They released it not too long ago. Syncfusion also released their grid not too long ago. Infragistics has had the longest lived WPF product suite. Grids are the most important component in my world. The other components are also important, but grids are king in my world.

I need minimally:

* Grid
* Docking/ MDI management
* Toolbars/ Ribbon
* General Editors

DevExpress

As far as grids go, DevExpress is my favorite WinForms grid provider. It is fast, flexible, good in every way. Their WPF grid is nice enough, but not nearly as plush as their WinForms grid.

Their other great component is their layout component. It is still not in their WPF Suite. Unfortunately, they only have a chart offering and a grid. They are not quite there yet.

* Grid
* Charts

Syncfusion

At one point (in WinForms days), Syncfusion was the darling of wall st IT departments. They were fast, the only one that did a good enough job supporting real time market data. At a point, the rest of the grid vendors caught up and in Developer Express’ case, surpassed Syncfusion. Their WPF grid offering feels immature to me. Aside from a grid they do have a more complete offering than say Developer Express:

* Grid
* Docking
* Several nice editors
* Charts
* Ribbon
* Taskbars/ Groupbars
* An auto-complete control

All in all, they have a nice package, notwithstanding the grid which as I mentioned - feels immature.

Component One

I have never really been a big fan of Component One. Their WPF Offering still has an uncomfortable feel to me. They currently offer:

* Grid
* Schedule
* Charts
* Reports

I have played with the grid a bit. I wanted to like it, but it just doe snot feel right to me… I realize that is qualitative, but so be it.

Infragistics

Well, Infragistics has the best grid currently. It does the most stuff, feels the realest, seems the most extensible. It just does what you expect. Now in WinForms land the Infragistics grid always had a big API, but it generally was SLOW. With my former employer we had several meetings with the people responsible for WPF at Infragistics and they were very reactive to our performance requirements. They also just came out with their Docking Manager, which was missing and important. Their current suite consists of:

* Grid
* Carousel
* Charts
* Several Editors
* Docking
* Ribbon

There are a number of smaller vendors that have one bit or another. This is OK for open source stuff - but I really do not want 10 different micro component vendors. Ideally, we could have 1 vendor. In the past I have almost always had 2 vendors - Infragistics for everything but the grid, then developer express or syncfusion for the grid.

Conclusion

I think that in conjunction with Prism, there is a farily compelling platform for building non-trivial front office trading applications presently. With the current ’stuff’ that is out there, we should be able to focus on the business facets, and deliver a real application in a timely fashion.

In or yard, we have the hugest spider web I have ever seen - by far. Now perhaps I have not spent enough time in the wilds of the wold, but this web starts AT THE PHONE LINE up some… 15 feet at least up. It runs across the stairs up to the outside - this stairway is likely 3-4 feet across. The ‘core’ of the web must be around 3-4 feet across, and the extensions run way up to the phone lines. Anyhow - here is a semi-good shot of the spider web.

It made for an interesting camera exercise. It is really the 1st time I was able to USE the manual focus WELL to achieve a purpose. I was able to lower the F down a bit to get the background blurred out a bit. I was able to use a prime lens (although I DID get some good shots with my Sigma zoom) and creep up to see it out a window. Cameras are cool - but I am SUCH an amateur, trying to use my prosumer Canon XTi. I also noticed that the image stabilizer for my Sigma zoom lens has been OFF… Lessons…

-Chris-

In this segment, we will discuss pushing in singletons that you have already created and adding a simple generic hook point.

Here is our starting test. We want to create something outside the container, then add it as a singleton.

This is trivial, we simple give it a delegate that returns that instance when it is called.

Here our lambda is just going to return that instance. (PS - this is a C# lambda expression, google it.).

But wait, what is wrong here… was it so trivial? Well, how about disposal? Do we want to dispose this thing when our container is disposed? I do not think so… So we can create a policy that does not dispose.

Here is a test:

Let us split our SingletonCreationPolicy into 2 parts - 1 that is the same in both cases - the creation bit, and 2 - the disposal bit we can ‘add on’ in only the case we want it in. This results in:

In our Kontainer class:

 the basic singleton creation policy is broken out (back to):

And finally, the Disposable version of the policy for ‘container managed’ singletons:

OK, so that code allows us to push singletons into the Kontainer and allows them to be disposed correctly. (Note the use of protected auto-properties. Less code - I like it).

Hook points

Many 3rd party vendors have used events as hook points for some time. I think grid control products like DevExpress’s XtraGrid have gone far and wide using events as the primary ‘hook points’ to their APIs.

In order to give similar behavior to SpringFramework’s IObjectPostProcessor, we can add an event for a similar effect. Let us start with a test:

We want to hook onto the point when a user is ‘getting’ an object. and ‘do something’ before they actually get it. In this case, we are getting drastic; we are completely replacing what the container has internally. Most usages would be more benign most likely.

We change our Get method, add a GettingObject event and allow callee’s to each have a go at the returning object. So our Kontainer class changes like:

This will happily allow callers to modify the created object and return to the ultimate caller of Get the result. It id the event listener’s perogative to elect to process the created object based either on the object itself or on the label.

So; there you have a nice way to push instances of objects into the container and a cheap hook point to ‘do stuff’ when the user calls to Get.

More soon;

Chris

I love being a dad. I have always been a self proclaimed ‘child monger’; making faces at kids on the subway and such. Kids generally like me and I like them. Kids generally smile at me, respond to me - and mostly they give me an excuse to act like a 3 year old myself.

Having just spent a few weeks with my kids; Gabe (who turned 6 yesterday) and Micah (3.5) and I have been thinking about them a lot. I aspire to be a good daddy. Gabe has told me on a few occasions that I am a ‘good daddy’ so I wanted to write up a quick retrospective of a few weeks with the kids - where am I doing well as a dad, where do I need to work, what do they respond to, etc.

My goals as a dad

• To make my boys know they are loved and valued
• To make my boys respect themselves and others
• To prepare my boys to be flexible to lives that change
• To instill in my boys the passion for whatever they find in their lives to care about
• To instill a love of learning in my boys
• To help prepare them to have healthy, meaningful, rewarding relationships with others
• To help them love and respect each other as brothers, people, and friends

My mechanisms for achieving these goals

• Listen to them, be attentive
• Give them boundaries and let them know where they are
• Talk to them at their level
• Put them in good schools
• Cooperate with my wife, align our expectations, talk about the kids
• Spend time with them one-on-one and with the whole family
• Use an even tone when speaking to them
• Think about parenting
• Read about parenting

Where can I improve?

After a few weeks of being with the kids all day, every day - here is what I think I can improve on:

• Micah is still ‘the baby’ a bit. I need to align myself with Gabe as much as Micah when there are arguments, battles, etc. Little boys fight - it is important to make them both know they are respected and have a voice when they get in a tussle.
• Patience. There is no end to the amount of patience that you need to have as a parent. My wife is more patient than I. I have patience, I could use more.
• Evenness of speech. I simply need to keep an even tone when speaking to the boys, when they are in a fight, when they are being nutty, when they are doing anything - I need to have an even tone. This is a ’subclass of’ patience I think.

Divisiveness/ Togetherness

Whenever you have greater than 1 child, it is important to drive them together. My wife Shannon and I work hard at driving our sons together and are very cognizant of ‘not driving wedges’ between our sons. It is very easy to be divisive or cause dynamics that make kids resent one another. “Why is HE getting all the attention?”, “Why am I always getting in trouble?”, etc. This is one of those areas that I think Shannon and I are doing well, but only because we are ALWAYS really thinking of how to avoid driving wedges between our boys, and focusing on how to coerce them into brotherly love.

Boundaries

I thought that the idea of boundaries and their importance needed a quick comment. I think that the concept of boundaries is one of the most central and critical concepts in parenting. Kids thrive on strucuture and expectations. Kids need to know where the ‘edges’ of their lives are. It is SO important (IMHO) to let kids know where their bounds are in their lives. How do you do this? Well, mostly by telling kids where the boundaries are, offering a penalty for violating (and the hard bit) following through with the penalty WHENEVER the violate the boundary. CONSISTENCY is KING with kids.

I read in some book about parenting once; (psuedo-quote) “Kids do not hear what you say, they hear the actions”. So if you say something like “if you color on the wall; then you will go to bed early”, then the child colors on the wall and they DO NOT go to bed early, then the kids learn they DO NOT REALLY HAVE A BOUNDARY.

A general concept in my life that I try to adhere to is; having a STRICT match between my word and my actions. Child rearing is one area of life where the benefits of this mantra are clear. It is clear that this is an important concept to live by in other relationships, work, etc - but in parenting - it is just in your face. When you violate your word, you kids learn that their boundary is NOT where you SAID, but where you acted. They learn you are malleable, and they try to push you and cajole you to sort out where that actual boundary is.

Anyhow - there is my humble 2 cents on being a good daddy. I am not saying I AM a good daddy, just that I want to be I will ALWAYS be improving in this, and I will ALWAYS need to improve here.

-Chris-

In this segment, we will make our stuff dispose nicely.

1st - let us look @ our creation policies in a bit more detail:

Here is the simplest possible one - a prototype creation policy. It will simply call the user’s func each time it is called, passing in the calling container for possible child dependency resolution :

The singleton creation policy is a bit more:

This policy uses the user supplied func to create a value 1x, then returns the value for all subsequent calls.

Now - why is this relevant? Well in order to dispose properly, we need to make our container disposable and implement that so - in normal form - here is a test and a little class to help test:

All we want to do is to dispose our container and ensure that any disposable items are disposed - for creation policies that want it as such.

So - we will add a dispose method to our container:

Our container has a field that is a dictionary of string to Definition. The list of values is a list of definition. If our definition has a disposable creation policy, we dispose it. This is using LINQ to select the values in an orderly fasion and a functional-esque call to dispose each in the ToList().ForEach(lambda) call.

We updated our singleton creation policy to look like this:

So - now our singleton creation policy will dispose singletons when the container disposes. If a caller supplies any disposable custom creation policy - it will also dispose as per their mechanism.

Now - I need to make sure that I throw exceptions ‘at the door’ when users provide bad data, or use the container incorrectly. After that, I need to make a pass at thread safety for the container…

In Part 1 of this short series, we outlined the basic behavior for the simplest possible DI container; what I’ll call Kontainer.

In this segment, we will write some code to make those tests pass. In order to allow us to make those tests pass, I wound up doing the following:

• Keep a list of definitions that are registered with the container
• Abstract the idea of an object definition
• Abstract the idea of a creation policy such that singleton and prototype are instantiations of a creation policy, but we could add other creation policies externally if we want.

This led to the following basic code:

The basic class to hold the definition:

The policy used to govern the creation of the objects in the user provided Function

A slightly modified version of the registry part of the container

and the basic bits of the core container

In order to test sub-property resolution, I also added the following test:

What is that all about? Well, the Function signature takes an argument for the calling container so that the class being built can resolve its own dependencies via the container.

This code was sufficient to make our basic round of tests pass. In addition, it was a little bit of relatively simple code. Furthermore, we can handle other creation policies aside from singleton and prototype. In order to prove that out, I added the following test:

 And the other test creation policy:

This is a ’singleton per thread creation policy’. This creation policy allows there to be a singleton created per thread. It uses primative locking style that we may change when we make the ‘whole shebang’ thread safe. Essentially - this will allow us to just prove out that we can supply alternate creation policies.

In the next part - we will sort our the disposal needs…

It is no secret to people who know me that am a HUGE DI proponent. When using a language like C# or Java certainly - you must do it to maintain a degree of flexibility, separation and manageability in their software.

I have used most of the DI containers. Last- I wrote one @ home over the weekend and brought it in to my last employer. In this series of posts - I am going to write a simple DI container, then go and make it threadsafe using some of Jeff Richter’s ’stuff’.

So how do I want this simple container to be?

• JUST DI, (not broad like Spring)
• Code based (no xml)
• Label based (not just type based)
• As little code as possible

Why those things??

Just DI 

I want it really, really simple. I have explained DI to people for some time and it is often obfuscated by whatever tool we are using. My ‘dumb simple’ explaination is usually something like:

When you are writing a class, and you need some other thing to help you carry out your behavior, in stead of newing it alive, depend on the appropriate abstraction and allow it to be injected. What do I mean by injected? I mean make a constructor arg or allow a settable property

Code based

I just want code - no XML, etc. It is a pain to debug etc.

Label based (below)

As little code as possible

I want AS LITTLE CODE AS POSSIBLE. I want to maintain NO CODE.

Constructor args or settable properties

Well - constructor args give you a ‘guaranteed fully baked class’ (as long as your arguments are ‘valid’ eg; not null, in the proper state, range etc). Changing constructor args can sometimes be a pain. They are also less amenable to odd circular dependencies (admittedly to be avoided anyhow). While I appreciate the value of constructor args - my general experience is that sometimes settable properties are more flexable. Take for example the case where you need to inject dependencies POST construction (in WinForms for example often the designer will ‘new’ your types).

Type based injection or label based injection?

Some friends of mine prefer type based injection. Some of the other current containers prefer type injection as well. Essentially the idea is that you ‘bind’ some abstraction to some single concrete implementation. For example:

// registration
diContainer.Bind(typeof(FooImpl))

// usage
IFoo f = diContainer.Resolve()

What I don’t like about this is that it forces you to have 1 implementation of IFoo in the system. This is OK in many cases, but it fights the ability to have N different implementations of a common interface. Take for example IPresenter or IView or something general like this. Binding a single implementation to something like this is prohibitive.

So - I prefer to have label based lookups. This has its own downside, mainly that you have to look for string names. With string based lookup - it is something like:


// registration
diContainer.Register("A", typeof(FooImpl)) // or some variation


// usage
IFoo f = diContainer.Resolve("A")


.. or something like that. The salient bit is the fact that you are asking for something by name, as opposed to just by type.

So I am comfortable using settable properties sometimes and names/ labels because:

• With tests, you can be a bit more dynamic
• It is generally a bit more flexable IMO
• With autoproperties, it is little code

So - what do I want the simple container to do?

• Allow me to register definitions for singletons using lambdas/ delegates
• Allow me to register definitions for prototypes (factory behavior)using lambdas/ delegates
• Allow me to register singletons that are already created
• Allow me to inject properties on instances of objects that already exist
• Allow me to get objects from the container by name
• Allow me to dispose objects when the container disposes
• Allow me to dispose objects when the container disposes
• Allow me to add behaviors externally via some hook points

Here are the basic starter tests then of Kontainer, my simple container:

With this set of tests, we get the following interfaces:

Well, here are some pics (we took ~1000 pics, this is a small ‘best of’ selection).

We went to:

• Saratoga (near Cupertino, Mountain View, etc.) to visit some friends that moved from NY (their lovely daughters are the ones with our boys in the photos - their best friends).
• Yosemite
• San Francisco

We stayed with our friends in their lovely place in Saratoga. We then stayed in Oakhurst (too far from Yosemite - but we reserved TOO LATE for a good hotel). I DO NOT recommend, the Oakhurst lodge - but at least it was clean and had a small fridge in the room. In San Fran we stayed at the Hotel Nikko - which I DO recommend - it was great.

=Chris=