Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Friday, October 30, 2009

CSLA .NET 3.8.0 Beta 3 is now available for download

Beta 3 includes fixes for some bugs found in Beta 2 (mostly in ViewModelBase and BusyAnimation), and two more significant changes:

  • InvokeMethod no longer attempts to manage the attached UI control’s IsEnabled property; this is a breaking change, but was necessary to avoid an otherwise unavoidable memory leak. It wasn’t a good practice anyway, so this implementation is both safer and better.
  • There’s a new Csla.Web.Mvc.CslaModelBinder class; it addresses a key issue around the data annotation validation attributes and how their validation information is reported back to the ASP.NET MVC framework. (I know I said Beta 1 was feature-complete, but this was too important to hold back…)

I’ve also continued to update samples, and I think all the C# samples are now updated, as are some of the VB ones. Hopefully I can get the rest of the VB ones updated before final release.

I am still on track to release 3.8.0 in about a week – hopefully Nov 6 or 9.

Friday, October 30, 2009 5:07:05 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, October 29, 2009

I’m not too sure about all this “manifesto” stuff these days. Certain right-wing politicians from days gone by are surely rolling in their graves. Then again, today’s highly communist/socialist oriented open source worldview would have gotten many of us into a lot of trouble just a few decades ago…

Regardless, there’s now the SOA Manifesto. And it seems to capture the spirit of SOA in a concise manner.

In fact, its opening statement, talking about putting business value above technology and so forth, seems to make sense for any software endeavor, not just ones that are service-oriented.

If you consider that SOA is much more of an enterprise architecture than it is an application architecture, this all makes a great deal of sense. The idea that applications should use service-oriented communication when they need to interact with each other is exactly the sweet spot for service-orientation.

In that context, saying things like external uniformity and internal diversity are good is clearly correct; because different applications may require different technologies or implementation choices, but they all need to work with some enterprise-standardized message-based service model.

I still suspect SOA may ultimately make a big difference in our industry. But I also think it will take decades to do so, just like object-orientation. People were working on object-orientation for well over 20 years before the ideas became mainstream. SOA is (if you are really generous) maybe a decade old, so it is probably time to work on some formalism so it is ready to become mainstream 10-15 years from now :)

Thursday, October 29, 2009 10:23:13 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Sunday, October 25, 2009

I have put CSLA .NET 3.8.0 Beta 2 online for download.

This completes the work for version 3.8.0, and (barring anyone finding a show-stopping issue) I plan to release 3.8 in just a couple weeks.

For Windows Forms and Web Forms users there are not any major new features, but some of the bug fixes may be valuable. Upgrading from 3.7 to 3.8 should be painless for these UI types (as well as XML services and workflow interfaces).

If you use WPF or Silverlight, you will almost certainly want to take a look at the features in 3.8. The downside is that there are several breaking changes in the XAML controls, but the upside is that the new XAML control implementations are far superior to previous versions. Controls impacted include:

  • PropertyStatus – now supports a “pull model” so a UI control can bind to properties of PropertyStatus, rather than having PropertyStatus directly manipulate the UI control’s IsReadOnly and IsEnabled properties. Also in Silverlight, PropertyStatus now makes use of the Silverlight 3 binding capabilities.
  • InvokeMethod – can now be triggered by any UI event, and can invoke a couple different method signatures on the DataContext. Also, MethodParameter is now bindable. The end result is that InvokeMethod provides really good support for both the CslaDataProvider model and the MVVM design pattern.
  • Execute – a new control that is a trigger action that works in the Blend 3 Interactivity model. This is very similar to InvokeMethod, but works with the Blend 3 scheme.
  • ViewModelBase<T> – provides a base class to make it easy to build a viewmodel class when using the MVVM pattern.
  • ViewModel<T> – provides a base class to make it easy to build a viewmodel class that works with InvokeMethod/Execute when using the MVVM pattern.
  • CslaDataProvider – the ObjectInstance property is now bindable, so it is possible to create master-detail (parent-child) relationships in the UI between different data provider controls.

See this blog post for more MVVM information.

Other important or interesting features include:

  • Support for System.ComponentModel.DataAnnotations validation attributes.
  • Performance enhancements for MobileFormatter, including the use of binary XML.
  • Better support for altering the behavior of IsDirty when using managed backing fields.

There are also numerous bug fixes, including (hopefully) a solution to the memory leak issue with BusyAnimation. See the change logs for more details about bug fixes.

Sunday, October 25, 2009 10:37:49 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 

I’ve blogged about MVVM several times over the past few months. If you watch my posts you’ll see that I started out pretty skeptical of the pattern, and then worked through it trying to find the shiny silver lining that was promised.

One of the biggest challenges with patterns is that people expect them to be a recipe, when in reality they are just a vague formalization of a concept. Just look at MVC, an incredibly mature pattern, and all the radically different ways it gets implemented (for better or often worse) in applications. While MVVM isn’t nearly as mature as MVC, it turns out that it really is a good concept – when “applied correctly”.

In my view a pattern should only be used if its positive consequences outweigh its negative consequences. Many patterns, oddly enough, require extra code and/or configuration over what you’d normally write – which is a negative consequence. And in some interpretations of MVVM this is very much the case – which was the primary reason for my initial skepticism.

On the other hand, with some thought, foresight and work it is often possible to mitigate some of the more negative consequences of many of the more popular patterns. This turns out to be absolutely true for MVVM.

To me, the real sweet spot for a pattern is if it can provide its positive consequences with little or no negative impact at all.

My time with CSLA .NET 3.8 has been divided into just a few areas:

  • Bug fixes (minor)
  • DataAnnotations (minor – but really nice)
  • Silverlight 3 element binding (major – also really nice)
  • MVVM support (major – and very cool)

In the end, I think I’ve got something that enables the use of the MVVM design pattern, probably in several variations, to work swimmingly with CSLA .NET. I’ll go so far as to say that I think this implementation of MVVM makes developing Silverlight and WPF apps easier than out-of-the-box coding (drag-and-drop, handling UI events, using data provider controls). And by easier I mean no more code, often less code, and easier to read/test/maintain code. So the pattern is purely helpful, with no negative consequences of note. Exactly what you’d hope for.

What does this look like?

CSLA .NET MVVM Support

First, you must realize that CSLA .NET helps you create what’s called a rich model as opposed to various other technologies (like Add Service Reference) that help you create an anemic model. Using MVVM with an anemic model is useful, but can require a lot of work, because your viewmodel object needs to compensate for all the stuff the model doesn’t do. But with a rich model, the viewmodel requires far less work because the model is already first-class citizen.

To this end, CSLA .NET provides some helper types that you may optionally use to enable a rich model MVVM implementation. At the same time, I fully recognize that many (most?) people will find/build and use an MVVM UI framework, so the CSLA .NET helper types can be used individually, all together or not at all – as you choose.

Two parts of MVVM already (mostly) exist if you are using CSLA .NET and Silverlight or WPF. CSLA .NET helps you create business domain objects that are your Model, and XAML helps you create your View (with a little help). So in my mind those are essentially a given. What’s left is the need to create the ViewModel.

Notice that I said XAML gives you the view – with a little help. This is because WPF commanding isn’t quite enough to do MVVM, and Silverlight doesn’t even have commanding. So the “little help” is something that handles arbitrary UI events and transforms them into arbitrary method calls on the DataContext (presumably your viewmodel). I would expect any decent MVVM UI framework to solve this most basic problem, and of course they do. Sadly there’s no standard solution, so each UI framework does their own thing.

View Event Handling

While not a UI framework, CSLA .NET does provide a basic solution to this one critical problem with using XAML to create a view. In fact it provides two solutions: InvokeMethod and Execute.

InvokeMethod is an attached property that understands how to handle an arbitrary UI event and to call an arbitrary method on the DataContext when that event is raised. As an attached property, you can attach it to any UIElement (FrameworkElement in Silverlight) to handle any event to call any method on the DataContext. Here’s a simple example:

<Button Content=”Save”
            csla:InvokeMethod.TriggerEvent=”Click”
            csla:InvokeMethod.MethodName=”SaveData” />

Execute is similar, but relies on the Blend 3 System.Windows.Interactivity event trigger concept to detect that the event was raised:

<Button Content="Save">
  <i:Interaction.Triggers>
    <i:EventTrigger EventName="Click">
      <csla:Execute MethodName="SaveData" />
    </i:EventTrigger>
  </i:Interaction.Triggers>
</Button>

The advantage of using InvokeMethod is that it has several options around data binding that simply aren’t available to a trigger action like Execute. Most notably, InvokeMethod has a MethodParameter property that can be bound using a binding expression – so it can pull values from other UI controls, resources, the DataContext, etc. There’s no way to do this with a trigger action like Execute.

The advantage of using Execute is that trigger actions are something the Blend 3 designer understands. So InvokeMethod pretty much requires typing XAML, while Execute integrates more naturally into the Blend design experience.

In either case, the method on your viewmodel looks like this:

public void SaveData()
{
}

Or this:

public void SaveData(object sender, ExecuteEventArgs e)
{
}

Either one is fine, as InvokeMethod and Execute will work with either method signature. If you use the second option, the args parameter contains information about the control the raises the event, the event’s args and an optional MethodParameter value.

Creating a ViewModel

When using a rich model, I believe that a good viewmodel object will expose the model as a property, so the View can bind directly against the Model and still have access to the viewmodel. This way the viewmodel can extend and enhance the model without any extra effort. This works particularly well if the model already understands data binding – which is one of the primary features of CSLA .NET.

CSLA .NET includes ViewModelBase<T> and ViewModel<T>, both of which are base classes designed to make it easy to build a viewmodel for a CSLA .NET business object.

ViewModelBase has a public Model property, a handful of other useful public properties (like CanSave), and a whole bunch of protected methods. Again, my assumption is that many people will use some MVVM UI framework, and that framework will have its own constraints on how public methods must be implemented for their particular “commanding equivalent” functionality. The ViewModelBase class allows you to create public methods matching your UI framework’s requirements, but you can usually just delegate those calls to existing protected methods that do most of the work. These methods include:

DoRefresh

(WPF only) Synchronously invokes a static factory method to create/fetch the Model.

BeginRefresh

Asynchronously invokes a static factory method to create/fetch the Model.

DoSave

(WPF only) Synchronously saves the Model (if it is a root object).

BeginSave

Asynchronously saves the Model (if it is a root object).

AddItem

Adds an item to the collection (if the Model is a BusinessListBase).

Remove

Removes an item from the collection (if the Model is a BusinessListBase).

Delete

Marks the Model for deletion (if the Model is a root BusinessBase).

Cancel

Cancels any changes that have been made to the Model (if ManageObjectLifetime is true).

ViewModel is a subclass of ViewModelBase that implements public methods for use by InvokeMethod and/or Execute. If you use InvokeMethod/Execute, then you’ll want to create your viewmodel objects by subclassing ViewModel:

public class CustomerViewModel : ViewModel<Customer>
{
  public CustomerViewModel()
  {
    BeginRefresh(“NewCustomer”);
  }
}

In many cases the constructor is all you’ll need to write, since the ViewModel<T> base class already implements the methods necessary to build a standard data entry form.

Again, if you are using an MVVM UI framework, you’ll probably want to create your own base class, somewhat like ViewModel<T>, by subclassing ViewModelBase<T> and implementing your public methods to match the requirements of the UI framework. You can use the code in ViewModel<T> as an example of how to do this.

I should also point out that the Model property is bindable. This means you can create “child viewmodel” objects that get their Model value by being bound to the property of some “parent viewmodel” or parent model. For example, you might have a form for working with SalesOrder objects, so your top level viewmodel exposes a SalesOrder object through its Model property. The following would be the XAML to set up the viewmodel for the form:

<UserControl.Resources>
  <this:SalesOrderViewModel x:Key="ViewModel" />
</UserControl.Resources>
<Grid Name=”LayoutRoot” DataContext=”{Binding Source={StaticResource ViewModel}}”>

Now you could just bind the detail region of the form (where you show the line items) to the LineItems property of the business object, and that works fine.

But suppose you want to bind a button or hyperlink control to an AddItem() method so the user can add items to the LineItems collection. How do you do that without writing code? The answer is that you set up a viewmodel (probably LineItemsViewModel) for that child region of the form, and you have the Model property of LineItemsViewModel bound to the LineItems property of the SalesOrder business object. In the child region you’d do something like this:

<Grid Name=”ChildRegionContainer”>
  <Grid.Resources>
    <this:LineItemsViewModel x:Key=”LineItemsViewModel”
                                           Model=”{Binding Path=Model.LineItems}”/>
  </Grid.Resources>
  <Grid Name=”ChildRegion” DataContext=”{Binding Source={StaticResource LineItemsViewModel}}”>

The advantage of this is that any controls inside the ChildRegion grid can invoke methods on LineItemsViewModel – such as AddItem() or Remove() to add and remove items from the collection – all with no coding on your part.

Creating the Model

This is the part where I just smile. Because you already have the model if you used CSLA .NET and good object-oriented design to build your business domain objects. The same business objects you may already be using for Windows Forms or Web Forms will almost certainly just work in your WPF or Silverlight application (assuming you are using CSLA .NET 3.5 or higher – and can upgrade to CSLA .NET 3.8).

The primary goal of CSLA .NET, first and foremost, is to enable you to create a business layer that encapsulates your business, validation and authorization logic into a set of business domain objects. By doing so, you end up with a formal business layer on top of which you can build Silverlight, WPF, ASP.NET MVC, Web Forms, Windows Forms, asmx service or WCF service interfaces.

So the whole point of having this business layer is that when something like XAML comes along all you need to worry about is how to rebuild the UI, possibly using MVVM. But you don’t need to worry about rebuilding the business layer, or the data access layer or the database.

I’m pretty happy with the way CSLA .NET 3.8 enables the MVVM design pattern in Silverlight and WPF. As I said to start with, you’d hope that a pattern gives you positive consequences with little or no downside. With the support of InvokeMethod, Execute, ViewModelBase and ViewModel I think CSLA .NET makes MVVM meet that goal. And in fact, I think it allows you to build a UI with less code than many, seemingly simpler, alternatives.

Sunday, October 25, 2009 10:23:04 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, October 22, 2009

I was just complaining that the cool new Windows 7 features weren’t available to me as a .NET developer – at least not without painful p/invoke calls.

My complaints were ill-founded however, as it turns out there’s a solution in the form of the Windows API Code Pack.

This makes me happy (though I haven’t tried it yet, so I’m just assuming it works) because I want access to Jump Lists and some other Windows shell integration concepts – which appear to be nicely included in the code pack.

Thursday, October 22, 2009 10:56:24 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, October 21, 2009

If you didn’t know, I’m an uber-geek in a family of uber-geeks, and that (of course) includes Star Trek, as well as supporting and being involved in the local fan community.

My wife is the fight choreographer for this play (and setting up fights with a batleth is really fun!). And the show itself is very good; good acting, well written script and a nice mix of action and comedy. It is a novel twist on an old story :)

About the Klingon Christmas Carol:

Scrooge has no honor, nor any courage. Can three ghosts help him to become the true warrior he ought to be in time to save Tiny Tim from a horrible fate? Performed in the Original Klingon with English Supertitles, and narrative analysis from The Vulcan Institute of Cultural Anthropology.

The Dickens classic tale of ghosts and redemption adapted to reflect the Warrior Code of Honor and then translated into tlhIngan Hol  (That's the Klingon Language).

A co-production of Commedia Beauregard and the IKV RakeHell of the Klingon Assault Group.

If you are in the upper-midwest region, I suggest you attend a show and see (according to the Klingons) the original Christmas Carol story.

Wednesday, October 21, 2009 9:20:36 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, October 20, 2009

Dunn Training is offering their CSLA Master Class next month in Atlanta

http://www.dunntraining.com/training/cslamasterclass.htm

If you want to get up to speed fast with CSLA .NET this is the class for you. Instructor Miguel Castro is a CSLA .NET expert and has contributed elements to the framework itself, as well as being the author of the courseware used for the class.

Sign up now!

Tuesday, October 20, 2009 1:28:14 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Monday, October 19, 2009

Microsoft has made Visual Studio 2010 and .NET 4.0 Beta 2 available for download to MSDN subscribers, with general availability soon. VS10 includes a lot of really nice features over VS2008, and I’m personally very excited to see the Beta 2 release.

I’ve made a pre-alpha CSLA .NET “4.0” available for download as well. This is really just the version 3.8.0 code (somewhere between beta 1 and beta 2) that I’ve updated to build under Visual Studio 2010 with .NET 4.0.

Over the next few months I’ll continue to release updates to version 4.0 that take advantage of the .NET 4.0 features, but I wanted to make sure there was a version online that builds with VS10 as soon as possible, so this is it – enjoy!

Monday, October 19, 2009 1:41:33 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, October 13, 2009

A lot of organizations rely on Gartner for valuable advice. Personally though, I remember a point in the mid-90’s where Gartner pronounced that Unix would be the dominant operating system long before 2009. Of course actual Unix is a total non-issue, having destroyed itself through fragmentation. Linux is still very meaningful, but that wasn’t what Gartner was talking about…

So when Gartner speaks, people listen – but if people are smart they’ll take what’s said with a big pile of salt.

Gartner apparently just came out with some thoughts on Windows 7. Mary Jo Foley has a summary.

And some of what they say rings true. Businesses really are more conservative than consumers about adopting new operating systems. So when Gartner talks about the lack of adoption and slow movement at the corporate level I tend to agree.

But Windows 7 really is a different release from what we’ve seen in many years. The caution expressed around maturity of the product, and shifting to 64 bit deployments is, I think, misplaced.

I can honestly say that I’ve never seen Windows be so smooth, and provide such comprehensive driver support before official launch. Remember, it doesn’t really come out until later this month, but Windows 7 64 bit is already more compatible with my computer than Vista.

Sure, an enterprise does need to run through a testing period, especially if they are upgrading from Windows 2000 or XP. There are changes, as you’d expect given that Win2k and XP are nearly a decade old. But 99.9% of the changes in Win7 are for the better – making the user’s life better, and the network/system admin’s life better.

My recommendation however, is for organizations and individuals to be aggressive in moving to Windows 7. This is because the transition is the smoothest I’ve seen in nearly 20 years of working with Windows, and the user productivity and sheer enjoyment are the highest I’ve seen since Windows 98SE.

(disclaimer: I don’t own Microsoft stock, so my recommendation here is based purely on my personal enthusiasm for Windows 7 and how much more fun my computers have been since I upgraded)

Tuesday, October 13, 2009 11:07:10 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Monday, October 05, 2009

One of the new features in CSLA .NET 3.8 is the ability to use the data annotation attributes from System.ComponentModel.DataAnnotations.

The DataAnnotations namespace was added in .NET 3.5 SP1, and includes a ValidationAttribute class that acts as the base class for validation attributes. An example of a validation attribute is Required, which is used to indicate that a property is a required value.

DataAnnotations are available in both .NET and Silverlight, though it turns out that their implementations aren’t quite the same. Still, their usage is the same, in that you decorate properties with data annotation attributes.

The idea behind DataAnnotations is that they are UI independent. If you put a Required attribute on a property, and then you build a UI using a technology that understands these ValidationAttribute subclasses, the UI will honor the attribute. The Silverlight DataForm is one example of a UI technology that does understand these attributes, and I suspect we’ll see many more UI technologies start to leverage them.

What’s interesting about this, is that the attribute object itself contains the validation rule logic. So the UI doesn’t actually implement the Required rule logic – it just asks the attribute object to do the evaluation. This is where things aren’t the same on .NET and Silverlight. On .NET ValidationAttribute subclasses override IsValid(), returning true if the rule is satisfied, false if not. On Silverlight ValidationAttribute subclasses override GetValidationResult() which returns null if the rule is satisfied, and a result object if the rule is broken. Either way the basic concept is the same, but the implementation code is different.

I wanted to support these attributes in CSLA .NET (for Windows and Silverlight). This is really a two-part process.

First, I needed to have a way to detect the attribute on a property, and attach a CSLA validation rule to that property so CSLA knows to execute the attribute’s rule when appropriate. CSLA .NET already has a business/validation rule subsystem that knows how to execute rules – I just needed to auto-add rules for data annotation attributes.

Second, I needed a way to execute any ValidationAttribute subclass, since that’s how one of these rules is evaluated. Again, CSLA .NET already has a validation rule subsystem that says validation rules are methods. So I just needed to create a CSLA-style rule method that knows how to invoke a ValidationAttribute to actually evaluate the rule’s condition.

I added a ValidationRules.AddDataAnnotations() method that you can call in your AddBusinessRules() override. This method reflects against your properties, detects any ValidationAttribute subclasses on any of your properties and adds a CSLA-style rule to link that property to the rule attribute. I also changed BusinessBase.AddBusinessRules() (this is the base method) so AddDataAnnotations() is called if you don’t override AddBusinessRules() – effectively making the use of data annotation attributes a default behavior.

Then I created a Csla.Validation.CommonRules.DataAnnotation() rule method. This is the rule method that is automatically associated with properties by AddDataAnnotations(). The DataAnnotation() rule method is pretty simple – it just executes the attribute object’s IsValid() or GetValidationResults() methods (depending on whether the code is running on .NET or Silverlight).

The end result is that when using CSLA .NET 3.8 you can apply data annotation attributes to your business class properties, and (assuming AddDataAnnotations() is called) they’ll be automatically linked into the normal CSLA .NET validation subsystem and executed like any other CSLA .NET business or validation rules.

[Serializable]
public class Data : BusinessBase<Data>
{
  private static PropertyInfo<int> IdProperty = 
    RegisterProperty<int>(c => c.Id);
  [Range(0, 10, ErrorMessage = "Id must be between 0 and 10")]
  public int Id
  {
    get { return GetProperty(IdProperty); }
    set { SetProperty(IdProperty, value); }
  }

  private static PropertyInfo<string> NameProperty =
    RegisterProperty<string>(c => c.Name);
  [Required(ErrorMessage = "Name is required")]
  public string Name
  {
    get { return GetProperty(NameProperty); }
    set { SetProperty(NameProperty, value); }
  }
}

Notice that this class doesn’t override AddBusinessRules(), so the base implementation is used, and the base implementation calls ValidationRules.AddDataAnnotations().

When AddDataAnnotations() is called, it detects the Range and Required attributes on the properties, and those attributes are automatically linked into the normal CSLA .NET business rule subsystem. This means the rules are automatically checked when a new instance of the object is created, and any time the property values are set – exactly the behavior you’d get with regular CSLA .NET rule methods.

But what’s nice about this is that these attributes are also honored by some UI technologies (like DataForm). This means that you automatically get the UI behaviors (if any) and yet you know that the rules will be run in the business layer regardless of whether the UI honors the attributes or not.

So this object will work nicely in the Silverlight DataForm, and will have the same business behavior in Windows Forms, behind a WCF service or anywhere else the object is used – even if the UI technology doesn’t honor the attributes.

You can also use this approach to create your own validation attributes by subclassing the ValidationAttribute base class in System.ComponentModel.DataAnnotations.

The only limitation I’ve found is that these attribute-based rules can only operate on a single property value. You can’t use this technique to do multi-property rules, or rules that operate on child collections or across other objects. You’ll need to use the normal CSLA .NET business/validation rule method approach to implement anything beyond simple single-property rules.

Monday, October 05, 2009 11:06:45 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Saturday, October 03, 2009

CSLA .NET version 3.8 Beta 1 is now available for download.

Beta 1 brings the WPF PropertyStatus in line with the Silverlight version.

And Beta 1 adds support for the System.ComponentModel.DataAnnotations attributes. Data annotation attributes applied to properties are automatically added as rules using the CSLA .NET validation rules subsystem when ValidationRules.AddAnnotations() is called in your AddBusinessRules() override. If you don’t override AddBusinessRules() the base implementation calls AddAnnotations() on your behalf.

The C# ProjectTracker has been updated to work with 3.8.

Saturday, October 03, 2009 10:07:14 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
October, 2014 (1)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014, Marimer LLC

Send mail to the author(s) E-mail



Sign In