Germán Schuager

Case-sensitive queries in NHibernate using SQL Server

gschuager@gmail.com (Germán Schuager) — Fri, 19 Jun 2009 14:21:00 +0000

Depending on the collation setting of your database (you probably already know this) the queries that you issue against it are treated as case-insensitive (CI collations) or as case-sensitive (CS collations).

If your database use a CI collation and you need to do some case-sensitive querying, the target SQL statement would be something like this:

SELECT u.Name
FROM Users u
WHERE u.Name like 'SomeName' COLLATE Modern_Spanish_CS_AS

Now, if you are using NHibernate you can do some things to make it help you issuing this kind of query.

The first one is to just use the Criteria API specifying the desired SQL expression:

var user = session.CreateCriteria(typeof (User))
    .Add(Expression.Sql("Username like ? collate Modern_Spanish_CS_AS", username, NHibernateUtil.String))
    .UniqueResult<User>();

This approach has the drawback that you tie your code to SQL Server specifically, and that will give you some headaches if you ever try to target another RDBMS.

The other (more elegant) option is to subclass the dialect that you are using (in this case MsSql2005Dialect) and register in it a custom function to perform case-sensitive comparisons.


public class CustomMsSqlDialect : MsSql2005Dialect
{
    public CustomMsSqlDialect()
    {
        RegisterFunction("sensitivelike",
            new SQLFunctionTemplate(NHibernateUtil.String,
                "?1 like ?2 collate Modern_Spanish_CS_AS"));
    }
}

Then you can use this new sensitivelike function inside any HQL statement and NHibernate will generate the correct SQL for you.

var user = session.CreateQuery("from User u where sensitivelike(u.Username, :username)")
    .SetParameter("username", username)
    .UniqueResult<User>();

This way allows you to support a different RDBMS just by registering the corresponding function implementation in a new derived dialect and without modifying your code.

Thanks to Dario for the tip.

Introducing NLaunch

gschuager@gmail.com (Germán Schuager) — Wed, 29 Apr 2009 14:58:00 +0000

In the last month I've been working in several desktop applications and faced the situation of having to remotely update my clients machines repeatedly. It is not fun. The process that I was using for accomplish this task was the following:

build the application locally (I'm not using CI)
upload the result somewhere (ftp, Mediafire, etc.)
notify the client that I will be logging in to do some work
log in remotely using Remote Desktop or LogMeIn (great tool BTW)
backup the current running version (just in case)
download and install the new version

I can tell you that it takes a lot of time to do these simple steps (and it is boring as hell) so I’ve decided to do something about it… I automated it.

The first thing that I’ve done is to evaluate the existing tools for this job. Here are some of them:

Clickonce

I had spent almost 3 non-consecutive days trying to integrate Clickonce deployment into my nant build scripts and I had failed; besides this, along the way I’ve discovered some limitations of Clickonce that made me look in other direction:

Target directory can't be specified, it will always deploy to the Clickonce cache
Not easy to deploy updates without running through the whole workflow (signing, uploading, etc). This means that you can't just recompile and xcopy the files to the target system (this is useful when you are at the client site).
Complex. Application manifest, deployment manifest, signing, mage (some things can be only done through mageui), etc, etc.

Updater Application Block

It has lots of functionalities, extensibility points and configuration options but it seems too big for my needs. I was looking for something simpler that just works with almost no configuration.

.NET Application Updater Component

Not looked at this enough. It is bundled as a component that must be dragged into a form of your application (didn’t liked that)

NLaunch

Anyway… those were some of the existing options, but I was looking for something a lot simpler, something that I hadn’t found, so I decided to write it myself.

My two main requirements were:

Dead simple: it must consist of a single executable file and maybe some configuration.
Unobtrusive: it must not require to add anything to the target application, it should work on its own.

The simplicity requirement have taken me to make a lot of assumptions and to apply some conventions (a good thing as long as they are documented) that may not apply in everyone's scenario, for this reason, I’ve created several interfaces first and then developed its implementations to fulfill my requirements; this would allow anyone to easily replace some of my implementations with its owns in order to adjust NLaunch behavior. Right now it is not easily extensible without requiring source code modification, but I plan to fix that in the future.

Now with NLaunch my deployment process is reduced to this:

Build the application locally and upload the results to an FTP server (all with just 2 clicks)

I can’t say that this is actually fun, but at least is it neither boring nor tiresome… because I don’t have to DO anything! :)

Well, enough writing for now, you can check out the project’s home page for a little more specific information and you can also download the source code (it is really simple) or a ready-to-work binary.

http://code.google.com/p/nlaunch/

Rich-client NHibernate session management

gschuager@gmail.com (Germán Schuager) — Mon, 23 Mar 2009 18:12:00 +0000

I've been struggling with this subject for quite some time now, and I've just seem to found the 'sweet spot'.

Before we start, I need to describe some facts about the target application:

rich-client: this approach will work the same for a Winform application as for a WPF application.
multi-screen UI: it could be multi-form or tabbed or MDI... the important thing here is that you "will" have several screens opened at the same time.
application uses an Inversion of Control container for wiring up dependencies among other useful things (I’m using Castle Windsor/Microkernel)

Ok.

Before we continue, I recommend that you read the work of Sebastian Talamoni, that although not finished yet, covers a lot of ground.

Basically there are 4 options for NH session management on a rich-client environment:

Session per application (per thread)
- the simplest approach
- only 1 session opened for the whole application lifecycle
- lots of problems: cache size, stale data due to other users, unrecoverable exception, etc.
- Fabio Maulo calls this pattern TIME BOMB
Session per screen
- 1 session opened for each form/tab/view/whatever
- implies multiple concurrent sessions
- since a single screen could be left opened for quite some time, this approach is almost equally susceptible to stale data as the previous one
Every data access - Fine-grained sessions
- every repository/DAO opens and closes a new session each time that a DB access is requested.
- loss of some useful NH features like lazy loading and 1st level cache… not worth it.
Session per use-case
- also implies multiple concurrent sessions
- this seems to be the right choice, however it is the most difficult to implement

Per-thread session management

Options 1 and 3 are easily implemented using some kind of thread-static session manager. Examples of this are Rhino.Commons and Castle NHibernate Integration Facility.

Each repository/DAO gets an instance of the a global "session manager" and uses it to get hold of the right session:

if 1 session per application is used, this "global" session is return by each call to SessionManager.OpenSession()
if fine-grained sessions are used there are two possibilities:
- we are in the scope of another session... the outer session is returned
- we are not in the scope of another session... a new one is created

The easy thing about this is that each repository/DAO can access to the "session manager" through some static accessor, or even better, they can receive a singleton (as in singleton lifestyle) instance as a parameter of its constructor, which enable us to use an Inversion of Control container to wire up these dependencies and ease the unit testing of these components (no statics = easier testing).

public class Presenter {

   private IBlogRepository blogRepository;

   public Presenter(IView view, IBlogRepository blogRepository)
   {
       this.blogRepository = blogRepository;
   }

   ...

}

public class BlogRepository : IBlogRepository

   private ISessionManager sessionManager;

   public BlogRepository(ISessionManager sessionManager)
   {
       this.sessionManager = sessionManager;
   }

   public Blog Get(int id)
   {
       using (ISession session = sessionManager.OpenSession()) {
           return session.Get<Blog>(id);
       }
   }
}

This pattern is suitable for a web application, where the context is usually given by the current request, but in a rich-client application it would imply that two opened screens (different contexts) would share the same session manager and therefore the same session when they intend to do some data access at the same time.

Contextual session management

Options 2 and 4 require another approach since they imply several simultaneous sessions through the lifecycle of the application. We can no longer have a static or singleton session storage from where to get the right session for each thread... we need some kind of "contextual session management" where each screen/use-case is treated as a different context and provided with sessions accordingly.

This don't seem so hard, right? We can just do something like this for option 4:

public class Presenter {
   private ISessionManager sessionManager;
   private IBlogRepository blogRepository;

   public Presenter(IView view)
   {
       sessionManager = SessionManagerFactory.CreateNewContext();
       blogRepository = new BlogRepository(sessionManager);
   }
}

The implementation of BlogRepository in this case is the same as before.

At first sight this seems like a nice way to define contexts, but that is until you realize that you are making very hard to unit test this class (hardcoded dependencies) and you are neglecting the help of the IoC container to wire up things.

Imagine that now, instead of BlogRepository we need something like AggregatorService that depends on BlogRepository, UserRepository and CommentService, and CommentService depends on UserRepository and CommentRepository. In this case, you'd need to create the session manager and then to instantiate every one of this components passing the right arguments to them.... this seems too much work for me.

Managing the dependencies yourself is not fun, and your IoC container enjoys doing it for you anyway.

Maybe something can be done using some kind of service location and passing the current context down the chain, like this:

container.Resolve<IBlogRepository>(With.Dependency<ISessionManager>(sessionManager)); // imaginary syntax
container.Resolve<IAggregatorService>(With.Dependency<ISessionManager>(sessionManager)); // imaginary syntax

but there is an easier way, let me introduce you to the…

Contextual Session Manager

This is an extension to the NHibernate Integration Facility of the Castle project that allows me to control the scope of my session and do not impose a global per-thread scope.

The solution is integrated by the following components:

ContextualNHibernateFacility: inherits from NHibernateFacility and all it does is to replace some of the standard components registered by the original facility specifying the right Lifestyle for the new ones.
ContextualPerThreadStore: inherits from AbstractDictStackSessionStore and provides a contextual session storage where there will be a different session for each instance of this class for each thread (tricky). The original CallContextSessionStore uses the call-context to store sessions, that means that two different instances of CallContextSessionStore will return the same session for the same call-context... this behavior is the one that I didn't like.
ContextualSessionManager: just inherits from DefaultSessionManager to specify a custom lifestyle (see below) to be use by Microkernel to manage this component.
ResolutionContextLifestyleManager: inherits from AbstractLifestylemanager. This is the “thing” that delimits our contexts. For more information go here.

This set of components allow me to use the container to resolve presenters, ViewModels, forms, or anything else that I’d like to use to delimit a context, like this:

var presenter = container.Resolve<IBlogPresenter>();

then, every required dependency (including the NH session manager) is resolved within the same context, all of this without even making any component aware of the existence of such grouping.

It is all handled by the container, which is exactly what I was looking for.

Sample Project

I’ve put together a small spike to illustrate these concepts. Maybe a more complex application would be more suitable to present some things, but for now this is all I’ve done.

The sample solution uses NHibernate, Windsor, NH facility, ATM (automatic transaction management) and a simple WPF UI using Caliburn’s Action support.

If you’re using SQL Server Express you just need to create an empty DB called “test”, otherwise just modify the settings in App.config to suit your needs. The tables and initial data are created by the application at startup.

You can download the sample here.

Improvements

One obvious thing that is left out here is the capability to resolve more than one root component for a given context (two repositories in two different presenters that get the same ISessionManager) but that is something that could be added with no problem.

There are probably a lot of scenarios where the approach described here does not apply… I’ve just implemented a solution to my problem that works well for me and I think that maybe someone else can benefit from this.

I would like to know what do you think about this approach.

Reporting Services + LocalReport hang

gschuager@gmail.com (Germán Schuager) — Mon, 09 Mar 2009 16:12:00 +0000

Just for future reference...

Winforms application + Reporting Services + LocalReport + bad luck = Application hangs without throwing any exception :(

I've just spend a lot of time trying to figure out what the hell was causing this issue.
It happened when I did this:

localReport.LoadReportDefinition(stream)
localReport.GetDataSourceNames()  // here it hangs 2 of 3 times

I've managed to get the data source names from the stream reading some XML but then it hung at another point where the report was referenced again... agrhh!

Researching a bit more and using Reflector a lot I've found out that the issue might have something to do with the report definition being compiled in another application domain the first time that it is required.

All in all, I've solved this issue by changing the threading model of my application from STA (single-threaded apartment) to MTA (multithreaded apartment) by changing this:

[STAThread]
public static void Main()
{
   ...
}

to this:

[MTAThread]
public static void Main()
{
   ...
}

Perhaps this can save somebody some time.

Contextual data using NHibernate filters

gschuager@gmail.com (Germán Schuager) — Thu, 12 Feb 2009 16:56:00 +0000

I'm in the middle of the development process of an application using NH for data access, and I'm faced with a requirement that could be stated as follows:

The application needs to provide support for different Contexts of execution, and certain entities must be context-aware, which means that at a given time, the application only sees instances of these entities that correspond to the current context of execution.

Now, just remember that I have several entities defined that are used throught the entire application layer stack, so I wanted to solve this issue modifying as little as possible.

I'm very proud with the solution that I came up with, and also very amazed by the power of NHibernate.

To simplify a little lets assume that I have a static class that defines the current context of execution:

public enum ContexType
{
  ContextA,
  ContextB,
}
public static class Context
{
  public static ContextType Current { get; set; }
}

Then, I create an interface that will be implemented by all the entities that need to be contextualized:

public interface IContextAware
{
  ContextType Context { get; set; }
}

Given a Cat class that needs to be contextualized, then I add the property to the class and to the mapping:

public class Cat : Entity, IContextAware
{
  ...
  ContextType Context { get; set; }
  ...
}

<class name="Cat">
  ...
  <property name="Context">
  ...
</class>

The idea now, is to use the dynamic filtering capabilities of NHibernate to only retrieve the Cats instances corresponding with the current context every time that a query against Cat is issued.
Typically this means that I need to add a filter definition to the mappings and the specify the condition for that filter in every class mapping that need to be aware of this behavior.
But there is an easier way to do this automatically:

var filterParametersType = new Dictionary<string, IType>(1);
filterParametersType.Add("current", NHibernateUtil.Enum(typeof(ContextType)));
cfg.AddFilterDefinition(new FilterDefinition("contextFilter", ":current = Context", filterParametersType));

foreach (var mapping in cfg.ClassMappings)
{
  if (typeof(IContextAware).IsAssignableFrom(mapping.MappedClass))
  {
     mapping.AddFilter("contextFilter", ":current = Context");
  }
}

Just do this (cfg is the NH Configuration object) before building the session factory and it creates the correct filter definition and adds the condition to every entity mapped that implements IContextAware.

At this point we just have our filter defined; now we need to enable it in order to actually filter something. It would be very handy if we can enable filtering at session factory scope, but since the session factory is immutable we need to enable it for each session that we will be using.

Wait.... maybe something else can do this work for us...

The following interceptor actually takes care of 2 things:
1. enables the context filter as soon as it is attached to the session, and
2. assigns the correct value to the Context property of entities implementing IContextAware when they are persisted.

public class ContextInterceptor : EmptyInterceptor
{
  public override void SetSession(ISession session)
  {
     session.EnableFilter("contextFilter").SetParameter("current", Context.Current);
  }

  public override bool OnSave(object entity, object id, object[] state, string[] propertyNames, IType[] types)
  {
     var contextAware = entity as IContextAware;
     if (contextAware != null)
     {
        int index = Array.Find(propertyNames, 0, x => x.Equals("Context"));
        state[index] = contextAware.Context = Context.Current;
        return true;
     }
     return false;
  }
}

Every session in the application needs to be created specifying this interceptor, but this should be an easy change (that depends on your architecture) if you are doing things right.

And thats all, the rest of the application is untouched and the requirement is fulfilled in a very elegant way.

Line count in Visual Studio

gschuager@gmail.com (Germán Schuager) — Wed, 07 Jan 2009 11:11:00 +0000

This is a nice trick that should be spreaded.

Select Edit -> Find & Replace -> Find in files... or just press CTRL+SHIFT+F

Check Use and select Regular expressions.

Type the following as the text to find:

^~(:Wh@//.+)~(:Wh@\{:Wh@)~(:Wh@\}:Wh@)~(:Wh@/#).+

VB.NET (thanks Steve for the info!)

^~(:Wh@'.+)~(:Wh@/#).+

Select where you want to do the search/count: file, project or solution.

If you select Current project or Entire solution, you also need to specify the file types that will be included in the search.

Proceed with the "search" and at the bottom of the Find results window you will see the total line count.

The regular expression that is used match every line that are not a comment (//), a compiler directive (starts with #), a single opening or closing brace, or blank lines.

Note:
This post is based on this one from Philip Stears (the regex in the original post does not work correctly).

Polymorphic query using interfaces

gschuager@gmail.com (Germán Schuager) — Tue, 23 Dec 2008 21:11:00 +0000

Given an object model defined by the following classes/interfaces:

public class Animal

public interface IHasFourLegs

public interface ICanFly

public class Dog : Animal, IHasFourLegs

public class Bird : Animal, ICanFly

public class Unicorn : Animal, IHasFourLegs, ICanFly

Suppose that you want to persist this class hierarchy to a database and be able to easily retrieve all the entities that implement one of both interfaces... then NHibernate is your friend (as always)

I've chosen to map this using the table-per-subclass strategy, but probably the other inheritance mapping strategies would work as well:

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                 assembly="Assembly"
                 namespace="Namespace">

<class name="Animal">
  <id>...
  <property>...
</class>

<joined-subclass name="Dog" extends="Animal">
  <key>...
  <property>...
</joined-subclass>

<joined-subclass name="Bird" extends="Animal">
  <key>...
  <property>...
</joined-subclass>

<joined-subclass name="Unicorn" extends="Animal">
  <key>...
  <property>...
</joined-subclass>

</hibernate-mapping>

Now that we have our classes and their mappings we are going to query our domain to get all the entities that implement ICanFly.

Basically you have 2 options right now: Criteria API and HQL.

Using Criteria API

This is very simple, all you need to do is this:

var flyers = session.CreateCriteria(typeof (ICanFly)).List<ICanFly>();

Using HQL

This one gets a little trickier (at least it got for me) since you need to explicitly import the interface type inside the mapping to get NH to know about it; this is simply done by adding the following line to your mapping:

<import class="Namespace.ICanFly" rename="ICanFly"/>

After this little addition we can issue a successful HQL query:

var flyers = session.CreateQuery("from ICanFly").List<ICanFly>();

Remarks

The import mapping needed when using HQL seems to be used by NH to map the string used in the query (ICanFly) to an actual type... if you'd have put rename="Flyers" in the import element then the HQL would need to be "from Flyers".

At first, I thought that specifying the full name of the type directly in the HQL string would have been enough, but it is not.

Take special care when trying to retrieve an ordered result set because since NH should issue several SELECT statements to get all the entities from the different tables (instead of using an UNION) the order of the results will probably be wrong.

Conclusion

This polymorphic behavior of NHibernate is just awesome because it allows you to be creative with your domain and frees you of the constraints imposed by the underlying relational model.

NHibernate Read-only property access

gschuager@gmail.com (Germán Schuager) — Mon, 22 Dec 2008 11:48:00 +0000

UPDATE: If you use the trunk you can now just do this (since rev. 3965):

<property name="Total" type="Decimal" access="readonly"/>

Keep reading if you are using an older version of NHibernate.

Recently I've asked in the NHibernate mailing list about how to map a property that is calculated in the domain but needs to be persisted in order to query data based on this property's value.

The thread is here and the sample I've used is the following:

public decimal Total
{
   get { return calculateTotal(); }
}

private decimal calculateTotal()
{
   return children.Sum(x => x.Price);
}

Basically, you have 3 options to persist this property.

1. Add an empty set method

This is the simplest but the ugliest of the three, you don't need to do anything else and it works just fine:

public decimal Total
{
   get { return calculateTotal(); }
   set { }
}

2. Use a nullable field to hold the value

Fabio suggested this approach:

private decimal total?;

public decimal Total
{
   get
   {
      if(!total.HasValue)
    total = calculateTotal();
      return total.Value;
}
}

public Item AddItem()
{
invalidateTotal();
}

private void invalidateTotal()
{
total = null;
}

In this case, the Total property is only calculated the first time that is required and its value cached, also you need to add calls to invalidateTotal() in every operation that would alter the result of the calculation.

Here you should use access="field.camelcase" when mapping the property.

As long as you don't call invalidateTotal() again, the calculated value is persisted and restored from the DB without processing the sum again.

This method is the most efficient, but requires you to put invalidateTotal() calls (and to don't forget about that) in some places... if you have a few calculated properties that each one depends on a few others it can get quite messy.

3. Read-only property accessor

Because of this issue, I've dove into NHibernate source code and tried to create a new property accessor that would allow me to map the domain that I really want without any hassle.

I was surprised at how easy I've found what I wanted to do inside that jungle.

I've created a JIRA issue with the patch ~~but so far it is not applied to the trunk.~~

In the mean time you can use the readonly property accessor from here mapping it using the custom accessor functionality of NHibernate like this:

<property name="Total" type="Decimal" access="Namespace.ReadonlyAccessor, Assembly"/>

(remember to replace Namespace and Assembly with the real namespace and assembly name where you put ReadonlyPropertyAccessor.cs)

This ReadonlyPropertyAccessor is working against NHibernate 2.0.0.GA and it needs a minor spell correction to make it work against the trunk... you will notice if you try.

So, here we are... those were the 3 options... choose whichever you like most.

CompactContainer new features

gschuager@gmail.com (Germán Schuager) — Wed, 26 Nov 2008 13:36:00 +0000

Last week I've found this post, in which Jeff Doolittle made an analysis of some alternatives about using dependency injection with the .NET Compact Framework.

As I've faced the same decision some time ago and ended rolling out my own solution, I pointed him to CompactContainer.

Apparently he likes the project but needs some features not implemented at the time. He sent me some patches and in the end we've added the following features to CompactContainer.

Attribute to mark the injectable constructor

By default, the container uses the constructor with most satisfiable (I thinks that's not a word...) dependencies to instantiate each component. This is the default behavior of Windsor/Microkernel.

Now, we have created an extension point where the default IHandler (responsible of creation and initialization of each component) can be specified and we've created an AttributedHandler that allows to select which constructor to use by means of an attribute.

The attribute type could be specified by the user when creating the AttributedHandler.

Take a look at the following example:

var container = new CompactContainer();
container.DefaultHandler = new AttributedHandler();
container.AddComponent(typeof(IDependencyA), typeof(DependencyA));
container.AddComponent(typeof(IDependencyB), typeof(DependencyB));
container.AddComponent(typeof(MyComponent));
container.Resolve<MyComponent>();
...

public class MyComponent
{
[Inject]
public MyComponent(IDependencyA a) { ... }

public MyComponent(IDependencyA a, IDependencyB b) { ... }
}

The first constructor will be used to create the MyComponent service even when all the dependencies for the second constructor are available.

Autoregistration of components

Jeff also added a feature where the container automatically registers concrete types when asked for them and they are not already registered.
This has required some improvements in the code base:

Specification of the default lifestyle (this can be improved a lot introducing something like ILifestyleManager to decouple the lifestyle's logic)
Generation of a default component key (based on the type) and overloads to the registration methods that don't require the component key and use the default one instead.

Example:

container = new CompactContainer();
container.AddComponent(typeof(IDependencyA), typeof(DependencyA));
var comp = container.Resolve<MyComponent>();

comp will be a singleton of type MyComponent and it is resolved ok even when the container knows nothing about it before the call to Resolve<T>.

To sum up here you can read Jeff's thoughts about CompactContainer. Thanks Jeff!

Open source rulez!

Custom Windsor lifestyle: ResolutionContextLifestyleManager

gschuager@gmail.com (Germán Schuager) — Thu, 06 Nov 2008 04:04:00 +0000

For reasons that will become clear in a future post (or later in this one), I needed to implement a custom lifestyle for Microkernel/Windsor. The required behavior was to propagate an instance of a component through the whole resolution chain but no further.

Let me explain it a little better.

The default lifestyle used by the container when none is specified is Singleton. This means that the first time that a service is resolved, the instance created is cached, and every other time after that, this same instance is returned.

You can also specify a Transient lifestyle, which indicates that every time that a service is being resolved a new instance is created.

What I was looking for here was some way to specify context boundaries in order that when the container is asked to provide a dependency for a given service within these boundaries, it will provides always the same instance, but when you are outside that context (or inside a different one) it will resolve a different (new) instance.
This behavior is achieved by the ResolutionContextLifestyleManager, that although it is not perfect at all (it is not thread-safe for example), fulfills my current requirements very well.

The implementation is based in remembering the type of the handler that initiates the resolution chain along with the instance just created, then every time that an instance is asked for within the same resolution chain, the cached instance is returned. It also hooks to the Kernel.ComponentCreated event in order to determine when the cached instances must be released (the resolution starter component has been created). It has grow a little messy to enable support for generic services.

I've put together the custom lifestyle with some tests in a solution that you can download from here.

The motivation behind this idea was to enable the usage of simultaneous forms in a rich-client environment where each one maintains its own context (NHibernate session manager in my current scenario).

Mutually exclusive checkboxes with jQuery

gschuager@gmail.com (Germán Schuager) — Wed, 03 Sep 2008 23:08:00 +0000

I was needing a way for the user to select none or just one item in a set... here is how I've managed to achieve this functionality using jQuery:

<html>
  <head>
      <script type="text/javascript" src="http://code.jquery.com/jquery-latest.min.js"></script>
      <script type="text/javascript" language="javascript">
          $(document).ready(function() {
              $('.mutuallyexclusive').click(function () {
                  checkedState = $(this).attr('checked');
                  $('.mutuallyexclusive:checked').each(function () {
                      $(this).attr('checked', false);
                  });
                  $(this).attr('checked', checkedState);
              });
          });              
      </script>
  </head>
  <body>
      <div>
          Red: <input id="chkRed" name="chkRed" type="checkbox" value="red" class="mutuallyexclusive">
          Blue: <input id="chkBlue" name="chkBlue" type="checkbox" value="blue" class="mutuallyexclusive">
          Green: <input id="chkGreen" name="chkGreen" type="checkbox" value="green" class="mutuallyexclusive">
      </div>
  </body>
</html>

A running sample is here. (Dead link)

(Based on this post. Thanks Tony.)

jQuery Autocomplete + JSON + ASP.NET MVC

gschuager@gmail.com (Germán Schuager) — Tue, 02 Sep 2008 23:25:00 +0000

It just took me a while to get this running, so maybe this could save you some time.

The requirement was to use the jQuery Autocomplete plugin to aid in the selection of some data coming from a database in an application using ASP.NET MVC Preview 4.

If you would like to see this plugin in action, refer to its demo page.

The documentation of the plugin states that when a remote source is used, the result must be returned formatted with one value on each line; but since I want to return a list of complex objects I would like to use JSON... googling around I've arrived to this page and learnt about the parse and dataType options that are not documented... using this options you can make the autocomplete plugin to receive remote data in JSON format.

So... this is the JS code that configures the plugin:

$(document).ready( function() {
  $('#signalName').autocomplete('<%=Url.Action("Lookup", "Signal") %>', {
      dataType: 'json',
      parse: function(data) {
          var rows = new Array();
          for(var i=0; i<data.length; i++){
              rows[i] = { data:data[i], value:data[i].SignalName, result:data[i].SignalName };
          }
          return rows;
      },
      formatItem: function(row, i, n) {
          return row.SignalName + ' - ' + row.Description;
      },
      width: 300,
      mustMatch: true,
  });
});

Here, I specify that the rows in the drop down will have the "SignalName - Description" format, and that the value that will be put in the textbox is the SignalName property of the selected item... this is done with the value property of the rows array.

The ASP.NET MVC controller/action that provides the data will be something like this:

public class SignalController : Controller {
  ...
  public ActionResult Lookup(string q, int limit)
  {
      var list = signalRepository.SearchByPage(q, 1, limit);
      var data = from s in list select new {s.SignalName, s.Description};
      return Json(data);
  }
  ...
}

To get this running, don't forget to include the required javascript files and the css to style the autocomplete drop down. Refer to the documentation for more information.

That's all for now.

MvcContrib parameter binder's: CastleBind vs Deserialize

gschuager@gmail.com (Germán Schuager) — Thu, 28 Aug 2008 17:20:00 +0000

I'm using MvcContrib in my first ASP.NET MVC based project...
I need to get an object built from the user entry in a web form, and to simplify this task I'm trying the ''parameter binding'' feature implemented in MvcContrib.

I've tested both Deserialize and CastleBind attributes and the first big difference I've found between them is that the Deserialize attribute tries to fill every property in the newed object whether the property value is contained in the Request or not. Since I'm using my business objects directly in my controllers (shame for me), this behaviour fires some properties setter that weren't intended to run.

The CastleBind attribute, which uses the Castle project Binder component, works as expected.

Prism.WindsorPrismAdapter

gschuager@gmail.com (Germán Schuager) — Mon, 09 Jun 2008 22:28:00 +0000

Here is a port of the Prism.UnityContainerAdapter assembly that uses Windsor as the IoC container.
It works with the lastest drop of Prism source.

You will have to resolve the references to make it compile.
It uses Windsor trunk (build 812)

Appending an attribute to a XML node

gschuager@gmail.com (Germán Schuager) — Mon, 12 May 2008 18:52:00 +0000

I just needed to append an attribute to a tag in a XML file, and it took me a while to figure it out how to do it from the command line.

The "easiest" way I've found is using a tool called XMLStartlet.

Some background... I am automating a Clickonce deployment through a nant build file and I need to specify in the application manifest that one of the files is a "Data File". I'm using mage to generate the manifests.

The app.exe.manifest XML file (application manifest) looks something like this:

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas-microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:co.v1="urn:schemas-microsoft-com:clickonce.v1" xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd" manifestVersion="1.0">

...

<file name="windsor.config.xml" size="819">
 <hash>
   <dsig:Transforms>
     <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
   </dsig:Transforms>
   <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
   <dsig:DigestValue>EO69DP0Ewj2rOeFxdwSaqN6NY1s=</dsig:DigestValue>
 </hash>
</file>

...

</asmv1:assembly>

My requirement was to append the writeableType attribute with value "applicationData" to the shown "file" node.

To accomplish this I've used this command:

xml ed -N a="urn:schemas-microsoft-com:asm.v1" -N b="urn:schemas-microsoft-com:asm.v2" -a "/a:assembly/b:file[@name='windsor.config.xml']/." -t attr -n writeableType -v applicationData app.exe.manifest

You get the resulting XML in the standard output (which need to be redirected), and the result contains:

<file name="windsor.config.xml" size="819" writeableType="applicationData">

The XML namespaces make it somewhat tricky to get the correct arguments for xml.exe, but when namespaces are not specified it turns out to be pretty easy and straightforward.

Remember also that if you want to include this command line in a nant script you will need to replace the double quotes with "& quot;" (without the space)

I think that XMLStartlet will be useful for me in the future, so this one goes to my toolbox from now.

NHibernate.Search with Castle.Facilities.NHibernateIntegration

gschuager@gmail.com (Germán Schuager) — Fri, 02 May 2008 02:57:00 +0000

A few days ago I was looking to add full text search capability to an application that uses NHibernate, so I took a look at NHibernate.Search.
The application also uses Windsor and the NH integration facility. This facility provides my repositories with an instance of ISessionManager (or ISessionFactory) which in turn is used to get the ISession.
Next, I will explain roughly what you need to do to integrate NH.Search with an application that uses the NHibertante integration facility.
At the end of the post you will find a link to download the full source code.

The first thing we need to do is to initialize the NH.Search engine. This is done in your application startup as follows:

var container = new WindsorContainer(new XmlInterpreter("windsor.config.xml"));
container.AddComponentLifeStyle("nhibernate.session.interceptor", typeof(IInterceptor),
                           typeof(SearchInterceptor), LifestyleType.Transient);

var cfg = container.Resolve<Configuration>();
var sessionFactory = container.Resolve<ISessionFactory>();
SearchFactory.Initialize(cfg, sessionFactory);

The registration of the "nhibernate.session.interceptor" component is required for ISessionManager to return us ISession's already configured to use with NH.Search.
Once we have everything in place we can define our repository class as follows:

public class PostRepository
{
private readonly ISessionManager sessionManager;

public PostRepository(ISessionManager sessionManager)
{
   this.sessionManager = sessionManager;
}

public IList<Post> GetAll()
{
   using (ISession session = sessionManager.OpenSession()) {
       ICriteria crit = session.CreateCriteria(typeof (Post));
       return crit.List<Post>();
   }
}

public virtual void Save(Post post)
{
   using (ISession session = sessionManager.OpenSession()) {
       session.Save(post);
       session.Flush();
   }
}
}

And the Post class...

[Indexed]
public class Post
{
private int id;
private string title;
private string content;

[DocumentId]
public virtual int ID
{
   get { return id; }
   set { id = value; }
}

[Field(Index.Tokenized, Store = Store.Yes)]
public virtual string Title
{
   get { return title; }
   set { title = value; }
}

[Field(Index.Tokenized, Store = Store.Yes)]
public virtual string Content
{
   get { return content; }
   set { content = value; }
}

public Post()
{
}

public Post(string title, string content)
{
   this.title = title;
   this.content = content;
}
}

Ok, now we have our repository and our entity. Now suppose that we want to add a Find method to PostRepository that returns all the Posts that contains a given text on its Title or Content properties.

This method could be implemented as follows:

public IList<Post> Find(string text)
{
using (ISession session = sessionManager.OpenSession()) {
   using (IFullTextSession fullTextSession = Search.CreateFullTextSession(((SessionDelegate)session).InnerSession)) {
       var queryString = string.Format("Title: {0} OR Content: {0}", text);
       try {
           return fullTextSession.CreateFullTextQuery<Post>(queryString)
               .List<Post>();
       }
       catch (ParseException) {
           return null;
       }
   }
}
}

The important thing you have to look at here is that ISessionManager.OpenSession() doesn't return a ISessionImplementor which is required by Search.CreateFullTextSession... instead it returns a wrapper of type SessionDelegate (used to control the closing of the session when it is inside a transaction scope), so in order to be able to create the full text session we need to use the ISessionImplementor that the SessionDelegate wraps around ;)

Using ISessionFactory instead of ISessionManager

Another way of doing this is using ISessionFactory directly instead of ISessionManager. In this case, the component name of the IInterceptor that you have to register at startup is "nhibernate.sessionfactory.interceptor" and since the ISession return by ISessionFactory.OpenSession() is in fact an ISessionImplementor, the creation of the full text search session is reduced to:

using (ISession session = sessionFactory.OpenSession()) {
using (IFullTextSession fullTextSession = Search.CreateFullTextSession(session)) {

Sample Solution

I have put together a sample solution that implements this concepts. It uses a SQLite database to save you from setting up the DB in a RDBMS, so it should run "out of the zip".
Although a winform application is not the optimal case to illustrate NH.Search usage (it is oriented to be used on server side components or in web applications) it serves the purpose of this post.
You can download it from here.

Inversion of Control container on .NET Compact Framework

gschuager@gmail.com (Germán Schuager) — Wed, 02 Apr 2008 00:40:00 +0000

Once upon a time I started to write an ambitiuos embedded application... I had very little knowledge about .NET, Design Patterns, TDD, DDD and all those cool things at that time.
My application grew over time and suddenly it became an unmaintainable monster. It was composed of a big web of interrelated components each of one did his work the way they wanted. It was full of singletons and static classes...

Since that time I've studied and learned a lot of usefull things like the ones that I mentioned above, and at some point I decided that I need to do something to prevent the monster from eating me.

This is where "The Great Refactoring" came in.... TDD... MVP... IoC!

Among other things I was in the need of a IoC/DI tool that works under .NET Compact Framework. The only one that I've found is uIoC but it lacks some features that I consider "must haves" for such a tool (constructor injection for example).
So, I decided to write my own Inversion of Control Container... so CompactContainer borns.

The API is roughly based on Castle MicroKernel and the main features are:

Constructor injection
Handlers for custom creation of different types of objects: I've used this to implement a PersistantaceHandler that attemps to create the asked component by deserializing it from disk, and if it can't then instanciate a new one in the usual way. This feature could be use to implement an IStartable interface with the same effect as the Startable Facility of MicroKernel. (not in the repository yet)
Lifestyles: Singleton and Transient (the only ones I've needed so far)

The source code can be found at http://code.google.com/p/compactcontainer/
Here you can find 2 solutions: one targeted to Pocket PC platform (can be retargeted as needed) and other composed of 2 project, CompactContainer and CompactContainer.Tests that is used to run the tests under the full .NET Framework (uses MBUnit).

My 2 cents...