Castle.MonoRail.Framework.IFilter - Part I

Today I would like to share some technique in using Castle.MonoRail.Framework.IFilter . I am a bit sad because it takes too much time for me to realize how useful, until I read between the line over and over again

Filters are executed before and|or after your actions. It is useful for security, dynamic content and to keep away repetitive code.

Keep away repetitive code is what I am tracing, let the hear the story shall we?

This happen with one of the real world project that I am working on Data Bridge like any other web application it need authentication and passing some user preference along each action (inherit from SecureController) to the view such as List, Add, Edit & Delete action & view.

This can be done using the following technique:

Create Filters\AuthenticationFilter.cs

public class AuthenticationFilter: IFilter
{
bool IFilter.Perform(ExecuteEnum exec,
IRailsEngineContext context,
IController controller){
if(!UserNotLogin())
{
Redirect("Login", "Index");
}
else
{
controller.PropertyBag["maxRow"] = GetUserMaxRowPreference();
... set more preferences as needed
}
}
}

Create SecureController

[Layout("default"), Rescue("generalerror")]
[Filter(ExecuteEnum.BeforeAction, typeof(AuthenticationFilter))]
public abstract class SecureController : ARSmartDispatcherController
{
}

SecureController is marked as abstract, prevent from direct use.

Using SecureController

public abstract class ProductController: SecureController
{
public void List()
{
}
}

Now view part: View\Product\list.vm

When render table I want to display miximum $maxRow rows.

See there is no code need to set preference in each action method, nice.

2007 Party of the Year :))

This party made especially for an old friend "Phors" he was on his scholarship assignment, Wish you all the best.

Happy New Year Everyone

IList you have me?

As much as I hate to deal with numerical index I had to cross it one way or the other so be it.
Here is the fact, I am enjoy using Castle.ActiveRecord to wrap my DAL code cuz it simplify thing a lot for me > 80% somehow when it came to not so complex scenario like this one:

I want to allow my customer to list all the products and set the qty they want to order.
If they already order I would like to give them a chance to update qty for the product that they miss in the previous hit.

public IList LoadProductOrderList(int customer_id)
{
IList result;
ISessionFactoryHolder sh =
ActiveRecordMediator.GetSessionFactoryHolder();
ISession session = sh.CreateSession(typeof(AnnualTarget));
try
{
// note: code wrapped for view
string sql = "SELECT p.pid, p.name, o.qty, o.id as order_id
FROM Products p JOIN Orders o
ON p.pid = o.product_id WHERE o.customer_id = :c1
UNION
SELCT pid, name, 0 as qty, 0 order_id FROM Products";

result = session.CreateSQLQuery(sql)
.AddScalar("ID", NHibernateUtil.Int32)
.AddScalar("NAME", NHibernateUtil.String)
.AddScalar("QTY", NHibernateUtil.Int32)
.AddScalar("ORDER_ID", NHibernateUtil.Int32)
.SetInt32("c1", customer_id)
.List();
}
catch (Exception ex)
{
....
}
finally
{
sh.ReleaseSession(session);
}

return result; <- this is an IList ?!!! I don't like to work with it }

As much as I hate, it is a bad idea to pass IList back to the caller object. What is interesting about this code session.CreateSQLQuery(sql) you can tell it to map the result to an Entity by call like this

session.CreateSQLQuery(sql)
.AddEntity(typeof(EntityObjectOfTypeActiveRecord))
.List();

But anyway I have got time to dig what AddEntity would do with the object pass in to me the road a head is a bit dark. Can I have something more simple?

The simple should be:

public IList LoadProductOrderList(int customer_id)
{
IList betterResult = new List();
.....
for(int i = 0; i < curobject =" (object[])" dto =" new" id =" curObject[0];" name =" curObject[1];" qty =" curObject[2];" orderid =" curObject[3];">

Now it much better to work with