Missing entry: setting DateTimeFormat.ShortDatePattern across the entire ASP.NET application

This entry is about a week overdue, nonetheless I shall post it now:

In the global.asax, before page execute, do this:

protected override void PrePageExecute(Page page)
{
// change short date pattern of the current culture short date pattern
CultureInfo info = (CultureInfo)CultureInfo.CurrentCulture.Clone();
info.DateTimeFormat.ShortDatePattern = "dd MMM yyyy";
System.Threading.Thread.CurrentThread.CurrentCulture = info;
base.PrePageExecute(page);
}



I'm using CompositeWeb.WebClientApplication here, if you are using vanilla ASP.NET, you can use a whole lot of different events such as BeginRequest.


Take the current culture, clone it (because the current culture is read-only).  Then set the short date pattern to something universal like "dd MMM yyyy";


This affects all instances where these are used:


datetime.ToString("d");
datetime.ToShortDateString();
datetime.ToShortDateTimeString();  // which is a concatenation of "d" and "t"
datetime.ToString();


This fixes issues for our application that is used by both American (MM/dd/yyyy) and Australian (dd/MM/yyyy) audiences.


Ideally, the user would set the language setting in their browser to the appropriate locale (en-US or en-AU), but this is too hard to force upon our non-technical users and the risk of someone misreading a date is too high, so we've opted for the "dd MMM yyyy" format which everybody understands.


jliu

Updating from SilverLight 2 Beta 1 to Beta 2

Cannot specify both Name and x:Name attributes

I think this is a bug in Beta 2, where you can't set x:Name for a UserControl, and then in the parent XAML that uses the UserControl, use x:Name again.

The trick is to remove the name from the XAML for the UserControl - you can use this in the code behind anyway to self reference the user control, so the name here isn't that important.

Update project references

Old SilverLight 2 Beta 1 projects still had references to version 2.0.3xx, some manual add/remove references was required to get the project all happily working on v2.0.50727

 

That was all the changes I had to do.  I think I escaped lightly this time.  Oh the joy of playing with beta software.

Modelling the system

image

 

Here's a nice pretty diagram of the various components of modelling a (any) world.

In my case here, the world is a virtual world.  You would noticed quickly:

  • The strong MVC reference.  If you really don't see it, try look at the colours
  • World is made of models - which are actually no different from a business application.  The same model pretty much applies
  • SilverLight 2 Beta 2 has strong work done on the visual manager, which I think is best used to utilize for rendering the world
    • In fact, in most games, the graphics component is the main component, in my little model here, it isn't.
  • The command logic is largely work from WPF's command syntax - in a business application, this means we can wire up multiple events to the same command (aka, control-C, menu)
    • In the context of a game, it means we can offer key-bindings and the user can choose what keys he'd rather use instead of the defaults
  • The blue part is the least ironed out section of my little model here - in a pure MVC situation, perhaps the Commands should be responsible for directly making the calls to the server / modifying the game objects.
    • Should I wait for server response before making the object move?  or should I trust the client and let it start moving, and allow the server to 'validate' the client's behaviour

One final work remains in this modelling exercise:

  • Some sort of dependency-injection for making it all work in SilverLight, this way, I can work on each component one at a time and have them plug in/out
    • And unit-test separately
    • There's some good work in the AssemblyPart class
      • Not sure about security implications though

Do we really need that many controls in Silverlight?

I was digesting Scott Gutherie's blog on Silverlight 2 Beta 2

We ultimately expect to ship over a 100 controls for Silverlight.

It really made me wonder, do we really need that many different types of controls built-in with the default Silverlight installation?

Beta 2 now has around about 30+ controls, and the only one that I've noticed is missing, is the combo-drop down list control.

I'm guessing if they really plan to end up with so many controls, then perhaps they'll start by porting across all the various controls that currently WPF have and Silverlight doesn't.

Edit:

Oh and some sort of Menu control

Lack of statistics for Windows spaces.live.com

The statistics capabilities for Windows Live wetted my appetite for better statistics reporting.  Why on earth:

  • Record only up to the last 3 days
  • No user detail breakdown - where from?  Unique visitors?  Returning visitor?
  • How are people finding my blog?  Word of mouth or blog reader or searching for keywords in Google where my blog showed up?

Anyway, the lack of statistics really is beginning to be a pain in the neck, makes me feel that no matter what I do, Windows Live spaces just doesn't support me to grow my blog, unlike other service providers like Blogger or WordPress.  (Both of them easily integrates with Google Analytics).

Which drives people back to use AdWords.

Sure we hate all things Google ;-)
But where's MS's offering?