Dragon MVC

I think the motivation factor is to lessen the scope of the project, so that I can get it done and write the documentation and unit tests for the project. If the scope is limited to just the controllers, database API, and view abstraction, then I can probably get something out in about 3 weeks time instead of trying to do many things at once.

I’m going to aim at keeping the components as separated as possible with some connections between the different parts. The view component is going to be the easiest and quickest to complete since it is just going to use PHP templates. I might finish the documentation for the Views first and complete the unit tests as well, so that the project gets off on a good start.

One component that I’m also going to to include is the plugin API. This will tie in to certain parts of the controllers, views, and DB API. I believe most of the real documentation will go into the database API and how to use that. The controller will also need comprehensive documentation, but just not as much as the database API.

I’m going to give myself a month and a half to complete the project with basically an hour a day on the weekdays and 2 to 4 hours on the weekend. I’m going to focus first on the unit tests and try to get as much of the API designed in unit tests as possible. Everything will have phpdoc inline documentation and have all main documentable elements explained. This will carry on to the DocBook documentation, which will try to explain in human terms how to use the library with examples.

Motivation

By giving myself sprints, I should put out a plan and be working on the project a little bit every day. By giving myself a little to complete and knowing exactly when I’m done, I can actually see the light at the end of the tunnel. By giving myself a deadline of a month and a half, I set forth a goal which I plan on completing.

The plan is to have the project functional before the month and a half, but most likely the majority of the planned features for the DB API will not be finished. The DB component will be the biggest part of the MVC and more time will have to be spent completing it. The foundation of the DB API should be fairly quick to complete and will allow for testing.

Previous Attempt

The previous attempt, I believe, failed because I was attempting to code it to replace WordPress without realizing that the API just isn’t going to be able to do that. After I realized that, I had already written the foundation and realized to get it to where it needed to be, I’ll have to rewrite it. I can still take some of the best parts of that API and apply it to the new API.

Instead, by starting over anyway, this attempt will have the design where I want it from the beginning. I think I’m still going to take some of the best parts of the WordPress DB feature set, including HyperDB code base. I’ve been experimenting with different implementations of what is currently in the code, so it is simple to replace the functionality and still allow it to be extensible.

Database API

The Database API is going to be Active Record and take what I’ve learn from CodeIgniter, ORM, Datamapper, CRUD, BREAD, and various other implementations of DB APIs I’ve done in the past. I’m going to try to correct the mistakes of other implementations and code the DB API to the best of my ability. This will not mean I won’t make mistakes on my own. This will be mostly a learning experience and I’m going to try new things in an attempt to simplify the code and how the code is extended.

My hope is to code the project in such a way to allow for experimenting, but also allow for “correcting” shitty code architecture that will creep in with such experimenting. Not all trials will work out the way they should and the API needs to be flexible enough to accommodate that. The other parts of the code base will not be developed in this fashion and the code will not use “experimental” code.

Possibly Related Posts:


Comments are closed.