I propose that we modify the folder structure for MantisBT. We have been discussing major changes to MantisBT for some time but seem to make little or no progress on the big features. Items under discussion include a UI redesign, using a framework, adopting an MVC pattern, templates, theming, and I'm sure many others.
I've been researching and implementing a template system in a local branch and have made some significant progress in this regard. However, the extent of changes required in the current codebase would make an
extremely disruptive update. We could tack yet another api onto core and add templates to the stack of extremely coupled and untestable apis. However, I think a better approach is called for.
I've set up a github branch
(https://github.com/daryn/mantisbt/tree/folder-layout) which restructures the mantis application closely following the Zend recommended project structure (http://framework.zend.com/manual/en/project-structure.project.html) although it may be a better fit for us to follow a categorized/namespace structure in the application directory. Also, Zend calls for configs to fall under the application directory. In order to facilitate users who need one code base to serve multiple mantis sites, I propose we add a CONFIG_PATH variable at the web server level which defaults to application/configs. All site customized files (strings, functions, config, constants) should be placed in this directory. I believe implementing this new folder structure will benefit Mantis in a couple of ways. First, it will remove a large portion of the application from the web tree by default. Second it will allow us to continue maintaining the current mantis application and begin to gradually rebuild mantis with modern development methods. This approach will also benefit the experimental manzen branch by making it much easier to keep changes from master synchronized in the branch.
After migrating to the new folder structure I propose upgrading the core application in three phases.
Phase One: Provide a template interface so we can move output from the apis into templates. Write classes that re-implement the current apis using Dependency Injection (DI) to decouple the dependencies and improve testability. For those new to DI, the simple definition is to provide dependencies in the constructor or in some cases through a setter. See the links below for a more in depth discussion of DI and why it is beneficial. I have no expectation that phase one will produce a "proper" or "valid" OO application. It
is simply a step to move us in that direction and allow us to more easily implement a
template system and even themes. Both are features long requested and long overdue. While this path may not be ideal, it is much better than attempting a complete OO
rewrite for the simple reason that I think we can actually get it done
in a reasonable amount of time.
Phase Two: Separate the business logic from the pages and begin migrating them to templates. Page logic is moved, one page at a time, from the web tree to the application directory and routed via controller. Unconverted pages are accessible through the existing url. When phase two is complete, legacy pages, apis, and classes can be deleted.
Phase Three: A thorough redesign of specific components using proper and complete modern methods.
Here are a few of the links I have found to be valuable resources for understanding Dependency
I look forward to your responses.