Hello Everyone,
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 Injection.
http://misko.hevery.com/
http://blacksheep.parry.org/archives/diy-di/print/
http://www.potstuck.com/2009/01/08/php-dependency-injection/
I look forward to your responses.
Regards,
Daryn Warriner
|
