From: Daryn W. <da...@ii...> - 2011-03-29 15:36:08
|
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 |
From: John R. <jr...@le...> - 2011-04-05 15:15:46
|
On 03/29/2011 11:35 AM, Daryn Warriner wrote: >snip As discussed on IRC, these changes have my approval. However, one thing we did not discuss on IRC that I would like to bring up relating to this restructuring: should we perhaps consider branching the current master branch to something like master-1.x, and use this restructuring, along with the rumored improved database api, along with the templating work that Daryn has been working, as a driving force for some "MantisBT 2.0" goal, rather than simply making it version 1.3? The only reason I bring this up is because the three of these changes are very likely to break just about everything from the existing 1.x series, including plugins, and could also give us a chance to cull some of the messier features from the core system. Things that come to mind: * dropping the custom function api in favor of plugin hooks * the long-awaited custom field overhaul * the long-awaited filter overhaul * improved authentication system Just a few random thoughts. Please beat me if you don't like them. |
From: Gianluca S. <gi...@gm...> - 2011-04-06 22:00:40
|
Hi Daryn and sorry for the overdue reply. On Tue, Mar 29, 2011 at 5:35 PM, Daryn Warriner <da...@ii...> wrote: > 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. Yeah, that's the logical next step after we landed the first part of layout reorganization in 1.2. However, I'm not sure doing this change now has compelling benefits for the 1.3 release. If anything, there is lots of documentation on installation that needs to be checked and eventually updated. So if the plan is to release a 1.3 rather soon, I'd probably prefer to use the current layout for it, branching now for stabilization and then land these changes in master. > 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. Let's say I hope so... right now it's a bit cumbersome to merge changes from trunk and I'm feeling more and more inclined to just use rebase instead. > > 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. > > 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. Sounds good. There are still potential pitfalls with this approach (sometimes it could be hard to implement the very same API, dependencies triggering more rewrites as you proceed, etc ) but I don't see any better method. > > Phase Three: A thorough redesign of specific components using proper and > complete modern methods. Does this include unit testing? I'm playing the database API right now and I bet I'd be already done with it if we had tests... Thanks for kicking off this plan, now just let's do it :) Cheers G. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: David H. <d...@hx...> - 2011-04-12 10:38:23
|
On Tue, 2011-04-05 at 10:59 -0400, John Reese wrote: > However, one thing we did not discuss on IRC that I would like to bring > up relating to this restructuring: should we perhaps consider branching > the current master branch to something like master-1.x, and use this > restructuring, along with the rumored improved database api, along with > the templating work that Daryn has been working, as a driving force for > some "MantisBT 2.0" goal, rather than simply making it version 1.3? I'd rather we stick to introducing a few major features per 1.x release so that changes are incremental. MantisBT 2.0 sounds like a project that will never be completed because it'll always be waiting on subsystem X to be rewritten. At the end of the day... what meaning does the transition from 1.x to 2.x have that isn't conveyed by 1.1.x to 1.2.x? The Linux Kernel uses the second approach with the 2.6.X numbering system. > The only reason I bring this up is because the three of these changes > are very likely to break just about everything from the existing 1.x > series, including plugins, and could also give us a chance to cull some > of the messier features from the core system. I agree. The main problem for 1.3.x plugins will be adjusting to the new XHTML5 output style and ban on inline Javascript. We should be aiming to provide backwards compatibility for the API changes (as Daryn suggested in the parent post). > * the long-awaited custom field overhaul One point I wanted to bring up again: this overhaul should merge custom field and built-in field functionality together so that code is reused where applicable. Regards, David |
From: Gianluca S. <gi...@gm...> - 2011-04-12 13:39:45
|
On Tue, Apr 12, 2011 at 12:36 PM, David Hicks <d...@hx...> wrote: > I'd rather we stick to introducing a few major features per 1.x release > so that changes are incremental. MantisBT 2.0 sounds like a project that > will never be completed because it'll always be waiting on subsystem X > to be rewritten. > > At the end of the day... what meaning does the transition from 1.x to > 2.x have that isn't conveyed by 1.1.x to 1.2.x? The Linux Kernel uses > the second approach with the 2.6.X numbering system. To me, it means that I can care less (if at all) about backwards compatibility; I'm not sure which "second approach" you refer to here, but kernel development is pretty famous for not having any kind of ABI/API stability guarantee (and this is also one reason people is paying big bucks to Red Hat to let their kernel team provide it in RHEL). For example, If I'm free to land in 1.3 an API change that breaks all existing plugins (or custom functions, or custom fields, or existing configuration, etc) then we can avoid bumping beyond 1.x forever. However, I was told in the past this was not really an option, so today I prefer to hack on the manzen branch when I can swap the ADODb backend with Zend and consider it something like Mantis 3.0. This is the only way I found to explore alternative development paths without hitting on some "we need backwards compatibility" wall. Just my 0.02 G. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: Jason S. <jsi...@gm...> - 2011-04-12 16:01:16
|
On Tue, Apr 12, 2011 at 5:36 AM, David Hicks <d...@hx...> wrote: > I agree. The main problem for 1.3.x plugins will be adjusting to the new > XHTML5 output style and ban on inline Javascript. Sounds great, but when you say XMTHL5, does that mean the plan is to publish Mantis pages with an XML media type or does that simply mean that the XHTML syntax will be used on pages published as HTML? Maybe this question has been answered elsewhere. Just curious about the direction of things. I've been focusing elsewhere for a while. -Jason Simanek |
From: David H. <d...@hx...> - 2011-04-18 13:22:24
|
Sorry this reply is late, my mail server failed to send it through earlier. On Tue, 2011-04-12 at 11:01 -0500, Jason Simanek wrote: > Sounds great, but when you say XMTHL5, does that mean the plan is to > publish Mantis pages with an XML media type or does that simply mean > that the XHTML syntax will be used on pages published as HTML? The 1.3.x branch is already serving up pages with a MIME type of application/xhtml+xml where the browser accepts this format with the Accept HTTP header sent to the server. Otherwise the fallback is to serve up the XHTML pages with a text/html MIME type. Ultimately MantisBT output needs to be well formed XHTML to cater for users who are being served content with the application/xhtml+xml MIME type. This has a number of benefits mentioned in previous mantisbt-dev discussion including: * easier to find bugs with page output (unclosed tags, XSS issues, etc) * ability to use automated XML parsing tools to assist with development, testing, etc of templates Regards, David |