Mar 28, 2009

Constanize the merb controller

I am implementing an authorization system now. There are two sub-system:
  1. Role based control system
  2. Rule based authorization system

The role sub-system is relatively easy to implement. I am going to talk about the rule based authorization system only here.

According to the requirement, the authorization system is very detail orientated. What does that mean? I can give you a very simple example here:
   For role 1, he can view e1, but can view, edit, delete e2
   For role 2, he can view, edit, but not delete e1, can view e3
   For role 3, he can view, edit and delete, archive e1, no any permissions on e2 and e3

In our system, we have 50+ entities, and maybe 20 roles. You can imagine how many possibilities you can have here. Thank god, I've designed the system mostly in the RESTful way. So the next problem is how can I get all the controllers and callable actions. There are two situations I have to address first:
  1. My controllers has name space
      Purchasing::PurchaseOrder
  2. My controllers not inherited from the Application directly, they might have their own hierarchy.

It turns out pretty simple in Merb and Ruby way.(This is another reason I like it over Java's reflection). The key is to Dynamically instaniating a class by name. Here is the code.

Mar 21, 2009

DataMapper - some tiny issues within 0.9.9

I am working on a home-grown authorization system. It is very customized for our special requirement. I have to hack DataMapper to get the job done. The more I dig in DM, the more I love it. I can't imagine how much code I have to write to do the same thing if I do it with Java. As a relative new ORM framework, it sure has some corners that might not work well for you, following are some thing I found out in one day:

1. auto_migrate! vs. auto_upgrade!