Tuesday, June 22, 2010
Wpf, Resources and DataContext
I've just worked on a view where we want to expose a collection in a next-previous way, and expose a 'CurrentItem' property. Whilst we could have done it in our ViewModel, in our scenario we don't want the ViewModels becoming aware of the next / prev, and just to be aware that they are given a list of items, and one of them is selected.
I went down the approach of a control which inherited from FrameworkElement as it had a DataContext then put it in the Resources Collection. Of course this didn't work as as we said at the beginning, stuff in the Resources cannot access the DataContext. BUT back up a minute... there is a control which seems able to do this - the CollectionViewSource. How does it do it? Heh heh, Reflector revealed the internal hack which MS used to somehow ram the inheritence of DP's into this unsuspecting class.
Nasty, but it just so happens we can exploit this for our own purposes. CollectionViewSource wraps a collection which it can obtain by binding to the DataContext, and it is not marked as sealed so we can extend it and add our own behaviour.
What I ended up doing was subclassing CollectionViewSource and adding a NextCommand, PreviousCommand, and SelectedItem dependency property to my subclass. (side note - we use a OneWayToSource binding to reverse the SelectedItem back onto the ViewModel we can bind to a standard .Net property on the ViewModel).
All sounds good, but there was one more issue. The CollectionViewSource is a bit of a liar, in that when you bind to it, you don't actually bind directly to it, but instead to the Collection it exposes. It makes for a nicer syntax in that 99% of times you use it, all you are interested in is that exposed collection. For us though we need to drill into our actual class to get at our subclasses properties. That's where that strange property on Binding, BindsDirectlyToSource comes in. It lets us probe past that outer facade of the class and get into the real object.
Our code is not far off being acceptable now. It looks something like:
<SummaryContentActionView> <!-- the scaffolding view which uses a template to define the layout -->
<SummaryContentActionView.Resources>
<NextPreviousCollection x:Key="col" Items="{Binding Contract.Items}" SelectedItem="{Binding SelectedItem, Mode=OneWayToSource}" />
</SummaryContentActionView.Resources>
<SummaryContentActionView.MainContent> <!-- object DP exposed from the scaffold contol -->
<StackPanel>
<Button Command="{Binding Source={StaticResource col}, Path=NextCommand, BindsDirectlyToSource=True}" />
</StackPanel>
</SummaryContentActionView.MainContent>
</SummaryContentActionView>
Saturday, June 12, 2010
Fun with NHibernate QueryOver and Linq provider
Given the following classes:
Blog
{
Guid Id
List<Post>
}
Post
{
Guid Id
Name
}
What's the best way to fetch a list of Blog ID's against the count of posts. Without going into HQL I've so-far got 2 ways, one using the Criteria (QueryOVer - nH3.0) and one using the NH linq provider. On a tiny database the results are quite interesting.
QueryOver needs to use a detached criteria and sub-select to get the results we need: we have to create 2 aliases, one for the select count bit of the query, and one to select over blog posts. We use a little trick with aliases to correlate the inner query to the outer query (correlated queries).
Blog outerBlogAlias = null;
Blog innerBlogAlias = null;
var innerQuery =
(QueryOver<Blog, Blog>)session
.QueryOver(() => innerBlogAlias)
.Where(() => outerBlogAlias.Id == innerBlogAlias.Id)
.Inner.JoinQueryOver(o => o.Posts)
.ToRowCountQuery();
Did you catch the alias bit – QueryOver(() => innerBlogAlias) – the clever bit is we can reference the alias used in the outer query following to correlate the two. That’s the line which reads .Wher(() => outerBlogAlias.Id == innerBlogAlias.Id).
var outerQuery =
session.QueryOver(() => outerBlogAlias)
.Select(
list =>
list
.Select(o => o.Id)
.SelectSubQuery(innerQuery));
This is the outer query – look how we use .SelectSubQuery(innerQuery), to capture the count of all the children posts in the main select statement. Neat huh?
OK, wanna see the same in linq-nhibernate…
var results2 = session.Query<Blog>()
.Select(o => new
{
Id = o.Id,
PostCount = o.Posts.Count
})
.ToList();
Done! And it even creates an anonymous class to hold the results. The interesting bit is the generated query. The QueryOver actually has to join Blog –> Posts. As a Post doesn’t hold a back reference to a Blog I can’t think of a better way to do this (other than changing the domain model which may or may not be acceptable). No such drama with the linq version though. It goes straight to the Posts table.
The lack of the extra join in a table with ooo, 8 posts, means that the QueryOver takes 61% of the query time (in sql), whilst the linq version only sucks up 39% of the overall time. Sql’s query plan for the QueryOver version shows that Sql Serve has to perform more work.
So what’s my conclusion – it’s that linq-nh, and queryover, are both really cool powerful query mechanisms. Each can do things the other can’t do, and you should not discount either of them up-front. Use the right query tool for the right job… And of course I should take my own advice and learn HQL as-well! For the record the reason I haven’t is that both QueryOver and Linq-NH are type-safe which is something I really like.
Saturday, January 02, 2010
C# to iPhone Objective-C
This set of blog posts is more for my own memory than anything else. I’m playing with iPhone development and wanted to draw similarities as-well as write down things I learn whilst getting to grasp with Objective-C.
So here we go. Let’s start at the beginning by looking at some core differences between the 2. The order might be a bit rambling but that’s just me writing stuff down that drops into my head! Soon I’ll try get onto the more visual aspects of iphone development but I think it’s essential to get your head around how to structure objective-c code before diving into guis.
For the record I learnt a lot from Dr Google, and this website was especially good: http://www.otierney.net/objective-c.html
1. Almost everything is a pointer.
To ‘create’ an instance of an object in Objective-C we tend to have 2 choices. The first involves ‘allocating’ memory for the object then ‘initialising’ it in some way. The 2nd involves calling a factory (think static) method on a class.
Whichever we do what we end up with is a pointer to an object. In Objective-C we must explicitly show this by using the * character. So to create an NSString object (a fairly core object) we can say:
NSString* myString = [NSString alloc];
more on the syntax in a minute.
To create the string object with a value:
NSString* myString = [[NSString alloc] initWithString: @”Hello” ];
Or you can say:
NSString* myString = [NSString stringWithString: @”Hello”];
The 1st two use instance methods on the NSString to initialize it. The 2nd uses a factory method to create the string. The main difference between the 2 is that by explicitly allocating the string (the 1st way) you are responsible for releasing the memory. With the 2nd way you aren’t. I’ll leave the specifics for another post as it deserves more time!
2. Calling a method on an object.
In C# / Java this is done via the dot (.) notation. So to call method Foo on object bar we say bar.Foo(). If we want to pass parameters to this method call we put them inside the parenthesis. So bar.Foo(someParameter);
Objective-C talks in terms of messages instead of method calls but for this example lets think of them as the same sort of idea. There are reasons for this as we’ll see soon. The syntax is weird at first sight -
[bar Foo];
means the same as bar.Foo(); in C# and
[bar foo: someParameter]
is the equivalent of bar.Foo(someParameter);
As you can see Objective-C looks a bit confusing at 1st sight especially if you’ve used C# Attributes before which use a square bracket notation.
3. Declaring a method on an object.
Objective-C uses Interface (header) files to declare members, methods, properties etc. that will appear in the class body. So you have 2 files. A .h and a .m file.
To declare a method we must add its signature to the .h file, and the contents of it to the .m file. Using the Foo.Bar(someParameter method) we end up with:
.h file
- [void] Bar: (NSString*) theParameter
.m file
- (void) Bar: (NSString*) theParameter
{
//do something
}
In a nutshell
the minus sign denotes an instance method rather than a class (static) method which would use a + sign.
[void] is the return value. In this case my method returns nothing.
Bar is the name of the method (followed by colon if there are parameters).
Then come the parameters. In this case I’m asking for an NSString* where the * means a pointer. Objective-C pretty much uses pointers for everything other than primitive values (int, float, etc). So-far (heh heh caveat alert) I haven’t seen a pointer being de-referenced explicitly as in C++.
To send multiple parameters is a bit weird:
- (void) setLatitude: (int) latitude andLongitude: (int) longitude
{
}
This method requires 2 integers. ‘latitude’ and ‘longitude’. To call this method we’d write:
[myFoo setLatitude: 98 andLongitude: 50];
Looks a bit bizarre huh?!
OK that’s enough for today. Next time I’ll try write about some other fundamentals – especially memory management (iphone’s version of Objective-C doesn’t have Garbage Collection).
Wednesday, June 17, 2009
Creating an Ellipsis (...) TextBlock in Silverlight.
So I recently had the requirement to truncate text in a Silverlight TextBlock when it is too wide to fit, and suffix it with '...'. Easy I thought - hah hah you didn't bet on Silverlight though! I thought I could do some things around
1. MultiBindings - bind the actualwidth of the textblock, and the string property. Pass them into a IMultiValueConverter and work out how much text can be shown. Unfortunately SL doesn't support Multi Bindings. Pah.
2. Subclass TextBlock. I hate using inheritance to solve these sorts of problems - I don't want to force people to use my own version of TextBlock - what if for some reason TextBlock gets extended in future and I've killed the inheritance tree.
3. Explicity grab the TextBlock in the code-behind and have a helper function to set the text whenever it changes. I’m working against ViewModels and want to keep my code-behind empty so whilst this might work it’s not what I’m looking for.
4. Attached Properties - the old attached behaviour via attached property trick. That’ll save the day – and here’s how it works:My first thought was an attached behaviour that would somehow get hold of the Binding, stash it, monitor it for changes, and create a new Text binding which would get the text with ellipsis where appropriate. SL doesn't allow you to get the underlying Binding though. Only set it. Pah.
So I decided Converters would be involved. Again, the problem was that I couldn't get the underlying Binding so I decided to make my one SL concession which was to ask the user of my new behaviour (EllipsisText) to pass me the Property they want to bind to as a string, instead of using a binding markup expression.
public static readonly DependencyProperty EllipsisTextPropertyNameProperty =
DependencyProperty.RegisterAttached(
"EllipsisTextPropertyName", typeof(string), typeof(EllipsisTextBoxBehaviour),
new PropertyMetadata(null, OnEllipsisTextChanged));
When this value is set I want to create a new Binding which will use a Custom Converter. The converter will need to know about the TextBlock though so it can get the maximum Width we have to play with.
private static void ConfigureEllipsis(TextBlock textBlock, string propertyName)
{
var binding = new Binding
{
Converter = new EllipsisTextConverter(textBlock),
Path = new PropertyPath(propertyName)
};
textBlock.SetBinding(TextBlock.TextProperty, binding);
}
Finally the converter – it is pretty simple. It takes the width of the TextBlock, then begins to measure how big the block would have to be to show the whole text. I do this by creating a new textblock, setting the font, etc to the same as the target one, setting the Text to the full string, then telling it to measure itself:
var textBlock = new TextBlock
{
Text = textToFit,
FontFamily = _textBlock.FontFamily,
FontSize = _textBlock.FontSize,
FontStretch = _textBlock.FontStretch,
FontStyle = _textBlock.FontStyle,
FontWeight = _textBlock.FontWeight
};
textBlock.UpdateLayout();
I can then begin to check the ActualWidth of this textblock against the width of the target one. Start chopping bits of the string (of course suffixed with ‘…’ when necessary) until the text fits in the allowed width. The TextBlock you are binding against needs an explicit Width set for this to work. The Layout pass hasn’t run when the converter fires and we need a Width to work with.
To use this all you have to do is:
<TextBlock Width="60" BehaviourExtensions:EllipsisTextBoxBehaviour.EllipsisTextPropertyName="BindingProperty" />
Full code:
public static class EllipsisTextBoxBehaviour
{
public static readonly DependencyProperty EllipsisTextPropertyNameProperty =
DependencyProperty.RegisterAttached(
"EllipsisTextPropertyName", typeof(string), typeof(EllipsisTextBoxBehaviour),
new PropertyMetadata(null, OnEllipsisTextChanged));
private static void OnEllipsisTextChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
var textBlock = d as TextBlock;
var propertyName = e.NewValue as string;
if (textBlock != null && e.NewValue is string)
{
ConfigureEllipsis(textBlock, propertyName);
}
}
/// <summary>
/// Creates a new binding on the text property.
/// </summary>
private static void ConfigureEllipsis(TextBlock textBlock, string propertyName)
{
var binding = new Binding
{
Converter = new EllipsisTextConverter(textBlock),
Path = new PropertyPath(propertyName)
};
textBlock.SetBinding(TextBlock.TextProperty, binding);
}
public static void ClearEllipsisTextPropertyName(DependencyObject obj)
{
obj.ClearValue(EllipsisTextPropertyNameProperty);
}
public static string GetEllipsisTextPropertyName(DependencyObject obj)
{
return (string)obj.GetValue(EllipsisTextPropertyNameProperty);
}
public static void SetEllipsisTextPropertyName(DependencyObject obj, string text)
{
obj.SetValue(EllipsisTextPropertyNameProperty, text);
}
private class EllipsisTextConverter: IValueConverter
{
private readonly TextBlock _textBlock;
public EllipsisTextConverter(TextBlock textBlock)
{
_textBlock = textBlock;
}
public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
if (_textBlock.Width == 0)
{
return value;
}
string textToFit = value as string;
if (textToFit != null)
{
var textBlock = new TextBlock
{
Text = textToFit,
FontFamily = _textBlock.FontFamily,
FontSize = _textBlock.FontSize,
FontStretch = _textBlock.FontStretch,
FontStyle = _textBlock.FontStyle,
FontWeight = _textBlock.FontWeight
};
int charsToChop = 0;
bool needsEllipsis = false;
do
{
textBlock.Text = textToFit.Substring(0, textToFit.Length - charsToChop) + (needsEllipsis ? "..." : "");
textBlock.UpdateLayout();
charsToChop++;
needsEllipsis = charsToChop > 0;
} while (
charsToChop < textToFit.Length &&
textBlock.ActualWidth > _textBlock.Width);
return textBlock.Text;
}
return value;
}
public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
{
throw new NotImplementedException();
}
}
}
Wednesday, January 21, 2009
Extending Asp.Net Dynamic Data
Part of my requirement was not to allow inserts / deletes to the tables. Only updates. Pretty simple because you have access to the aspx / ascx templates and can literally remove the buttons / links and change the data sources to not allow inserts / deletes just for added protection to hand-crafted http posts.
You can create partials of the classes generated by Linq-Sql and attach attributes like MetadataType, or DisplayName to change the name of the table in the generated pages, or switch off columns from the dynamic scaffolding. You can also change columns in the linq-sql model to make them read-only. Nice :o) All is good in the world!
Not so fast though! The next requirement of course was to expose a table which absolutely must be inserted / deleted into. Damn! There didn't appear to be an in-built way to allow insert / delete for some tables but not others (not that I could see). But the answer was simple (so if there is an in-built way I don't have much code to change!!) and here's how I did it.
The template asp.net pages all have a MetaTable instance injected into it which amongst other things exposes an Attributes collection. These attributes are the Attributes from the table-model class, in my case the MetadataType / DisplayName attributes. So all you have to do is create another attribute, slap it on the partial classes, and pick it up from MetaTable.Attributes. In my case I created an attribute with two boolean properties, CanInsert and CanDelete. I also added an extension method to the MetaTable class, again CanInsert and CanDelete. The extension methods runs a quick query over the attributes to see if the attribute is there, and if so what the boolean value is. It looks something like this:
public static class MetaTableExtensions
{
public static bool CanInsert(this MetaTable table)
{
var attribute = table.Attributes.OfType<TableExtensionAttribute>().FirstOrDefault();
if (attribute == null)
{
return false;
}
return attribute.CanInsert;
}
}
The asp.net template pages can now easily look for this attribute in for example the OnRowDataBound event of lists, and make a decision on whether or not to show a Delete button / Insert link.
Simple but effective.
Thursday, January 15, 2009
Hand-crafted IOC in Asp.Net MVC
That's great, but sometimes you just don't want the baggage of a Container hanging around, especially if you are writing a small-ish solution. I faced that scenario today and stumbled upon what I think is a really elegant solution!
The problem... I want to inject dependencies into Controller classes, but don't want to use a container.
The solution... OK, bear with me it's easy!
In the global application_onstart method I have the opportunity to construct a custom ControllerFactory and pass it to Asp.Net. I won't cover that. Try here for more information.
My initial thought was to have a ControllerFactory expose a Register<T>(string name) where T:Controller method. That would let me register a Controller against a name, and then do an Activator.CreateInstance to create it. But of course in the real world the whole point of IoC is that the Controller will have dependencies it needs satisfying so this approach is kind of lacking!
One option I thought of was to have a Builder class for each Controller which would know how to create its Controller. I could RegisterBuilder<T>(Builder<T> builder) where T:Controller. Now my ControllerFactory can grab the appropriate builder and just ask it to Build(). The builder would be specific to a Controller so can create it concretely. It works, but it could lead to an explosion of Builder classes.
Then I remembered my old friend Func<>. It's nothing new really and is just a concrete implementation of a Delegate we could have written in .Net 2.0 - delegate T Func<T>() I think is the signature- don't have Reflector to hand. It allows me to do something like this:
ControllerFactory.Register<T>(Func<T> buildController) where T:Controller.
My global.asax can now look something like this
var provider = new DbConnectionProvider(Configuration.ConnectionStrings[....]);
var customerRepository = new CustomerRepository(provider);
var controllerFactory = new ControllerFactory();
controllerFactory.Register<HomeController>(() => new HomeController(customerRepository));
When a request comes in to the ControllerFactory it can say something like:
Dictionary<Type, Func<Controller> _controllerDictionary;
...
_controllerDictionary[controllerTypeToBuild]()
The syntax might look a bit weird, but essentially the dictionary contains functions which build a particular type. So when we grab something from the dictionary we just have to execute it hence the () call.
No container, no builder classes. Just everything wired up ready to go in my application start-up.
That might pose an architectural question of 'What do you mean by wiring up your application at start-up?' To answer than let me link you to Misko Hevery's blog - a google guy with some awesome posts on writing testable applications.
Sunday, January 11, 2009
Learning OLAP and Analysis
One technology I'll be working with over the next few months is OLAP. It's a technology that I've always seen as slightly Voodoo-ish, Black Magic like, akin to walking into a mysterious smoky room with a pointy bearded Wizard lurking over a Crystal Ball!
Over my next few blog posts I'll aim to break down some of the mystery and offer some laymans descriptions to OLAP - what it is, how it works, and how to work with it. For my first post I'll describe some of the key terms, along with some links that I've found useful on understanding it better.
Measure
This one is pretty simple. Whenever we analyse some data we are analysing a particular type of information. It's usually a numerical piece of data and some examples might be Sales Amount or margin, GST, VAT, etc.
Dimension
Starting with an example, lets I have some Sales Data against time. The total amount taken be a store per day. In this case my dimension is time! Simple huh? I might ask my OLAP database to show me the sales total against Time.
As another example my sales data might also be broken down against location. I can ask my OLAP database to show me sales data for 2004 in Australia. We've defined another dimension, location.
Cube
No more black magic. Think of a cube - it's a simple 3-dimensional object. Lets say I have a cube where the X-dimension are my 'measures' - sales amount, margin, units sold, etc, my Y-dimension is time, and my Z-dimension is location.
You should start to see how we can form a query to the cube along the lines of "Show me the total margin, in February 2008, in Western Australia". The Performance Point video I'll link to shows this beautifully, but take the cube and take the 'Slice' of the cube representing Margin. Then cut another slice of the same cube and get the WA slice. Finally cut a 3rd slice along the time dimension for 'February 2008'. What you'll end up with is one piece of the cube where these 3 slices intersect which happens to contain the data we're after. Simple huh?!
Enough for now. Next time we'll either look into more detail around the Cube, or take a look at some of the query language (MDX) we use to write the queries to it.
Nice MS video on cube basics
Wikipedia on OLAP
Nice introduction linked from Wikipedia
Updated 4:55pm removed the Slicing and Dicing quote. Not sure if that's what slicing and dicing is!!