The Insanity I Am Working On, Zend Framework based MVC alternative.
So it is no secret I haven't had as much time to work on the Refactoring Code blog posts as much as I would have liked to lately. For a while I was pulling serious over time, hadn't started going to the gym like I said I was going to, and not really getting enough "me" time in general. I cut back to a more reasonable amount of mixed Overtime/Personal Project time and started the gym routine and also going to a couple of local gaming groups. My blood pressure is _real_ happy about that.
Aside from the refactoring projects, I've also been working on a code framework that spawned from a structured authoring framework. I sat down to code my ideas for a Structured Authoring Framework, based on a data model (called FLORA) that I've been working on only to find that I needed a code framework to make the coding process manageable. I like Zend_Framework, but I am not a fan of MVC in general. It's not that MVC isn't good in theory, it is just that I have yet to find an implementation I can live with.
My main work project has similar framework needs. It is internally called "Journey" because it began with the idea of being able to track personnel data over the course of a person's employment with the Library, it balooned out to include features like managing personal information and membership groups in our Active Directory, Intranet/Document management (though fortunately it looks like we will be attempting to use Confluence for that particular functionality) and in general being a backbone database for all non-ILS data related to the business of the library. Journey's scope became so extensive that has been dubbed the "E-Matrix of Library Administrative Data" (E-Matrix is the internal name for our internally developed ILS integration layer).
To meet the needs of these two ambitious projects I decided to first lay down a foundation with a framework based on my experience with other large scale projects. It is a roughly MVC pattern, but with some concepts that make it particularly well suited to hybrid Application/SOA style implementations. The idea is that one can build an application and underlying services in tandem, the application is primarily supported by the services and additional "glue" code. The services also provide ready-made resources for other applications. The frameworks also needs a high level of database abstraction so that the database can be highly relational (as my boss puts it, "overly normalized") without exposing the complexity of such implementations. The framework needs to:
The end result is finally coming in to focus. I've settled on a temporary name of QP for the project "short for Quick Project), it is internally named "Quepie" since "QP" is a bit too short to be unique.
The backbone of the framework is a searchable registry/tree, called the Datatree. The tree is divided into primary branches called "directions". These were originally input and output directions, but since a configuration branch has been added, and others are conceivable. The idea behind directions is that searching always happens in only one direction, input and output are effectively firewalled off from each other, so accidentally using user input (or any input for that matter) becomes less likely. Each direction is further divided into branches which may contain other branches, or may contain a set of data. Each branch that accepts data can have a filter assigned to it, and all data that goes onto that branch is run first through the filter. A search of the tree can be as general as direction + data name, or can specify any one or more possible branches. The idea is to make it easy to search for something specific, or allow for a more generalized search.
As mentioned, the framework is very data type oriented, so there is also a component that handles the registration of different data types, and the appropriate filters, validators, and decorators (for various forms of output) for each. It is appropriately called the Datahandler. The Datatree uses the Datahandler to manage the filters for each branch.
More later. (I'll also try to add some pretty diagrams).
Aside from the refactoring projects, I've also been working on a code framework that spawned from a structured authoring framework. I sat down to code my ideas for a Structured Authoring Framework, based on a data model (called FLORA) that I've been working on only to find that I needed a code framework to make the coding process manageable. I like Zend_Framework, but I am not a fan of MVC in general. It's not that MVC isn't good in theory, it is just that I have yet to find an implementation I can live with.
My main work project has similar framework needs. It is internally called "Journey" because it began with the idea of being able to track personnel data over the course of a person's employment with the Library, it balooned out to include features like managing personal information and membership groups in our Active Directory, Intranet/Document management (though fortunately it looks like we will be attempting to use Confluence for that particular functionality) and in general being a backbone database for all non-ILS data related to the business of the library. Journey's scope became so extensive that has been dubbed the "E-Matrix of Library Administrative Data" (E-Matrix is the internal name for our internally developed ILS integration layer).
To meet the needs of these two ambitious projects I decided to first lay down a foundation with a framework based on my experience with other large scale projects. It is a roughly MVC pattern, but with some concepts that make it particularly well suited to hybrid Application/SOA style implementations. The idea is that one can build an application and underlying services in tandem, the application is primarily supported by the services and additional "glue" code. The services also provide ready-made resources for other applications. The frameworks also needs a high level of database abstraction so that the database can be highly relational (as my boss puts it, "overly normalized") without exposing the complexity of such implementations. The framework needs to:
- provide a type based data with a rich library of filter/validation/decoration tools,
- provide multiple views into the data provided by the service layer,
- handle authentication/access concerns for access to the service layer, and
- integrate well with the non-MVC portions of the Zend Framework in general to cut down on the code base.
The end result is finally coming in to focus. I've settled on a temporary name of QP for the project "short for Quick Project), it is internally named "Quepie" since "QP" is a bit too short to be unique.
The backbone of the framework is a searchable registry/tree, called the Datatree. The tree is divided into primary branches called "directions". These were originally input and output directions, but since a configuration branch has been added, and others are conceivable. The idea behind directions is that searching always happens in only one direction, input and output are effectively firewalled off from each other, so accidentally using user input (or any input for that matter) becomes less likely. Each direction is further divided into branches which may contain other branches, or may contain a set of data. Each branch that accepts data can have a filter assigned to it, and all data that goes onto that branch is run first through the filter. A search of the tree can be as general as direction + data name, or can specify any one or more possible branches. The idea is to make it easy to search for something specific, or allow for a more generalized search.
As mentioned, the framework is very data type oriented, so there is also a component that handles the registration of different data types, and the appropriate filters, validators, and decorators (for various forms of output) for each. It is appropriately called the Datahandler. The Datatree uses the Datahandler to manage the filters for each branch.
More later. (I'll also try to add some pretty diagrams).