In Prometheus I have a system schema xml file that defines the classes in the target system.  For code generation I have found it useful to classify the classes into subtypes. There are generally utility classes such as Lookup which provides the lookup table functionality, common classes such as name, address, email etc which are re usable common classes and then there are business objects.  The business objects are the main classes of the system where most business logic is concentrated.  Common types like Address may contain some simple validation but not too much if any system level business rules.  However a particular instance of Address may have some additional logic. 

An Example:

A Home object is one of the main objects in the system.  A home has an address.  A home also has a customer (buyer) and the customer (buyer) has an address.  Address is the common type and Home is the business type.

So here is the topography:

Home.Address

Home.Customer.Address

We have a business rule that says the customer should be able to update his/her own address but not the address of the Home they are buying.  This is a place where field level security can be useful.  Based on the topography listed above the customer role would have access to Home.Customer.Address.* but not Home.Address.*.  The asterisk indicates that the user can have permissions to all fields (value or object type) of the parent object.  Our topography gives us a context in which to view two similar objects in a different way.  Even though both objects have similar validation and are saved in the same address table they can have different permissions and/or functionality as needed.  

This is just one more step in the 80/20 code generation solution.  If I can achieve 80% of the functionality I need through code generation and the rest through custom coding then I can greatly enhance my productivity.  Code generation is nice in many ways but in this case it allows us to apply a consistent set of generation rules and build hierarchies of objects to which permissions can be applied in a consistent manner. 

I’ve implemented two things that will enable a fair amount of progress.

The first is a lookup table implementation.  Any name/value pairs can be stored and retrieved from the persistence engine (database, etc).  This makes population combo boxes, list boxes etc very easy.  The search is performed on the object and field.  So for instance a type of car could be search by car & category and then all matching values will be returned.  I have built this into the generation code so that all properties that have an attribute=”choice” will have their UI code load the choices.  This is a possible candidate for caching.

The second system wide feature is field level security.  This is a typical role based security system where each user is assigned one or more roles and each role is assigned permissions to each object, method and field.  This is context driven so that that a customer.name has different permissions then a builder.name.  I’ve built an AccessControlList table in the database and then each field can be queried by its distinguished name i.e. customer.name.  This feature is still experimental but should allow a very manageable security infrastructure for CHT.  This is another candidate for caching.