DragonU Bug Tracker Dev – Milestone 1

Posted by Jacob Santos on February 6, 2011

Framework

I decided to build my own framework using Zend Framework as a base. The basis of which is going to have a mismatch of directories. I might look at Habari, Fuel framework, and Kohana framework to see how they structure their directories and files. At this moment, I’m going a mix of WordPress and what I remember from CodeIgniter. Not the best choice to be sure. However, I plan on improving the nonsense after I go over certain details and get the base working how I like.

I switched from Fuel, because Zend Framework has more of what I need to get started faster. The only downside is that I need to setup the controllers and functionality. I might instead, create a branch, that uses CodeIgniter 2 for the MVC for rapid prototyping to be sure that the application is how I want it while I build the official framework for which the application is going to be based. I’ll create this as a branch, if I am going to develop this way. I’ll have to see how quickly I can get the base up and running.

If I get this working, I’ll most likely use it for my other projects, but I might attempt to implement the features into FUEL instead.

Core Application

The core application, I’ve decided is going to be based on Zend Framework and I’m going to make the following changes:

  1. Kohana Style Front Controller. The front controller is going to allow for modules and plugins, which will also have controllers, so most likely, I’m going to set it up to where it first searches the official Router and if it is not found to look at the directory structure for the controller. I like the way CodeIgniter and its clones allow you to easily add controllers without actually setting up the routing, except for the more advanced purposes. I’m going to implement a hybrid system between Zend Framework predefined routing and CodeIgniter style routing.
  2. WordPress Style Script and Style Loaders. I hate having to change the headers and what not and using styles and scripts that aren’t even used on the page. The code will not be from WordPress, since I’m going for New-BSD license, but I’ve already built something similar, and the algorithm is simple, so I won’t have to worry about this feature taking too long. I am going to attempt to add script collisions to prevent duplicate javascript files from being added.
  3. WordPress Style Filters and Actions. I’ve already started code for this and I’m think I’m going to go an easier route for implementing the feature. It will be the 3rd rewrite and 5th overall. I’m looking at probably 4 or 5 hours given how long the other attempts took.
  4. Themes. I do like the way WordPress does themes, so I’m going to attempt to implement this. I’m going to include an API for extending existing themes, setting dependencies, and using the default theme if missing files. The differences from WordPress is that Modules will also define default templates that themes may override. It will be done in such a way to prevent conflicts; the theme module template files will be in a separate directory, ‘modules’ and use the name of the module. In this way, a theme does not need to know about all modules, but may provide for those it knows about and popular themes.

    It also allows for placing themes and their additions in one place. Users do not need to put module theme files in the module directory, just the directory of the theme they are using. Given the parent-child nature, if they want to support multiple themes, they can put the modified theme file in the default theme (which is a parent of every theme by default) or the parent or child theme.

  5. Modules. See below section on this.

    The goal of the modules is to provide additional features for the Bug Tracker that can be enabled and disabled. Modules may have plugin support, theme support, but most importantly will have separate controllers and models and are basically separate and mini applications for the bug tracker.

  6. Plugins I want the difference between plugins and modules to be that plugins are mostly filters and actions for existing hooks, with maybe an options page. For this, I’m going to include an API for setting the options page, if one is needed. I really want to emphasize the purpose of plugins over modules, so that the confusion of when you would implement one verses the other. I have a feeling that eventually one or the other will win out if I don’t force the issue. Modules will offer Plugins as well, and this may help with the issue of when you would do a Module verses Plugin.

    Probably include something similar to WordPress widgets, but I always hated how it was implemented in WordPress, so I’m going to go for something different.

  7. Hybrid Settings Configuration. Setting up and configuring the application should never require editing files, unless the initial database configuration file could not be made. The problem is that this often requires using the database to store the settings. I really don’t like doing that. The base application will attempt to create PHP configuration files for core and module configuration, but will use a database table, if that fails.
  8. Enabling Plugins and Modules will also have two ways to do so. You could enable modules and plugins by including a file named, “.enabled” in the module or plugin directory, but enabled modules and plugins will always be checked in the database. I might also include a third way, which is a separate config file, which loads modules and plugins. I may also attempt to create this similar to configuration.

Extensible Administration and Separate Front-End

One of the concepts I’ve thought on was having a default administration for the application that modules and plugins could extend and themes could customize. I figure actually that customization will be very limited. Only the header, navigation placement and footer will be editable, as well as the CSS and Javascript.

The reason for this is that modules and plugins have their own controllers and I don’t want to force mixing or moving directories. I want modules to be contained applications that all you need to do is drop it into the modules directory and enable it. To this end, the administration of modules has to be combined with the base application administration controllers. It should also give modules complete controller functionality within their scope.

I was actually thinking about including a member profile as a separate system similar to the administration. However, this I don’t think will be necessary as modules and plugins will be able do this anyway. The separation was given the fact that navigation and theming will be different from the front-end and back-end and therefore will need a system to ensure cohesion.

Installer

WordPress has spoiled me, I believe that any application that does make it extremely simple to install, isn’t worth using. To this end, there will be an basic installer that checks against certain requirements and runs queries for installing the database tables.

In the future, I want to allow downloading plugins, themes and modules during the installer process, as well as configure them. This milestone, I’m going to simply work on simple database specific configurations, so that the application can be installed. The rest of the configurations will be done in the administration.

Modules

I’ve already discussed some of my plans on this feature, but really, the purpose of modules is to separate several features of the application into components that the administration can enable to extend what the base application can do. I figure if all you want is simply a ticket tracker, that simply install the application and run with it. If you want a support ticket feature, then you’ll enable the module that implements that feature or any feature you want.

Several planned modules, but not in this milestone:

  • Support Ticket.

    Help and support tickets that aren’t bugs, but would be helpful for future requests and reference. Might be used internally for customers. Will be extremely simple in structure and UI and include public option for allowing anyone to create a support ticket.

  • Company Projects.

    The base application will assume that only one company is using the application and therefore all projects belong to it. Again, this will be a boilerplate module for extending and allowing for this feature. This will really force the base application to allow setting the default controller, overriding defaults, something that is already planned, but in a way to allow for cascading default controllers.

    The feature will most likely test the cascading controller in a certain of filter system for setting the priority of controllers. So you could have segments matching against multiple modules. This may require allowing the administrator to set up the priority in case there are conflicts.

    So for /{Company}/{Project}/

    The company module will add its priority as 1 and the Project priority, which is in the base application will be priority 10. So in theory, you could have another module come along and add region, which would make it, “/{Region}/{Company}/{Project}/” and since the Region will also be priority of 1 will notify the administrator of this conflict and force modifying the priority, so Region is always first and Company is always second.

  • Repository Activity

    There is a difficulty with implementing this feature in PHP. That is, that the implementation will require command line applications and also access to the CLI git, svn, hg, etc on the system for the repositories. Given this requirement, as well as the esoteric feature set in Trac, Redmine, etc. I mean it seriously isn’t strictly necessary for bug tracking and managing projects. It is “nice to have” feature and I plan on using it for statistics of developers.

    One element that I’ll implement when I see how it is done in other bug trackers and project management applications is how to get the application to work with Tortoise SVN and Tortoise GIT ticket features. I’m going to attempt to add this as part of core, but the ability to close tickets in the repository commit log will have to be part of this module or implemented as a plugin.

Note About Configuration

The configuration will be file and database based. An attempt will be made to create PHP file configuration, but given any permission issues, the database with caching will be used instead. The purpose is to make the application as easy to modify as possible without having to modify any PHP files. The application is require as little work as possible to setup and configure as possible, but also attempt to be as efficient as possible.

Planned Features In Later Milestones

The first milestone is about getting the base framework working to start adding application functionality. Other planned functionality includes automatic upgrading of the application, modules, plugins and themes.

This will quite possibility use the same system as WordPress, but implemented for this web application framework. The library that WordPress uses is freely available and I believe uses a license compatible with this web application. I will need to implement it separately as WordPress had to include work arounds and WordPress specific code to get the installer and upgrader working. The worse case is to use a separate library or libraries for implementing a similar feature. Well, actually, what is cool about these libraries, is that it might allow for using file based configuration even if access is not granted for creating those files, since the main library is creating files using FTP or SSH tunnel.

Possibly Related Posts:


Projects

Comments are closed.