With the last commit (and push) I’ve completed the html export of BugEverywhere

After the suggestions from W.Trevor King (who also give me a good insight about bzr workflow) I added two other options for the command (–export-template and –export-dir-template).

The first one simply export the default template in the default directory, the second one let you to specify a custom directory as target for the export. This default template can be used as starting point to write a custom template for the export.

Trevor also added two options to let you to personalize the title and the index header of the export (–title and –index-header).

At this point, if no bugs are found, I think the export is complete.

 

Just pushed to my branch the new template system for the ‘html’ command of BugEverywhere.

Now there is a default template hardcoded in the command, and a new option (-t|–template-dir template_directory) that can be used to pass a different template for the html export.

The template itself is a simplified version of the previuos one, and with the -t option is no more necessary to modify the source code to modify the look of the output, but just put in one directory 4 files:

  • style.css
  • index_file.tpl
  • detail_file.tpl
  • comment_section.tpl

The tpl files are just normal html files, and of course the css file is a normal css file ;-)

As a bonus, there is also a verbose option to have a complete output of the command execution, very useful if the command is executed with a cron job.

 

After too much time, I do some new work on BugsEverywhere. The main task for now is to merge my branch with the main branch and the Trevor’s -rr branch. After the merge, the idea is to complete the the html export and start to work on other things like target precedence and so on.

 

After some delays, I finally have an initial implementation of the html export (see bug 2f0 in the main branch for details)
At the address www.grys.it/~gian you can find an example output for the command.

Looking at bug ’4dd’ you can see also how the comments are handled.

I’d like to hear about suggestions about the result

Things left to do order by importance:

  1. align the code standard to the rest of BE source code
  2. implement the possibility to select an output path
  3. have a small summary on the top of the index page
  4. use a different color for each status
  5. general html layout improvements (table headers for example)
  6. ability to use a template system ?

As soon as I implement at least points 1 and 2, I will set up a public branch to checkout the code.

Technical information.
For now I use only one file to implement the command. This means that also the html part is in the same file.
All the html templates are implemented as a separate class, so it is simple to move them to other files.

 

I am still working on BE. This time I am working to implement from scratch a command to get the output of the bug list as a series of static html pages. This begun as a python script that parse the .be directory directly, but since my first patch was merged, I changed my mind and begin to work to a full be command implementation.

The sintax (still not complety defined) is very simple

be html [--output=output_dir]

This generate in the output_dir (or the default directory that is ./html_export) some statics html pages with the list of the bugs. I have not yet defined how to show the data, I like the ditz output but I’d like to have the bugs list divided by status, with some general information about themĀ  (like the number of total bugs, how many are in each status and so on)

For now I have a basic implementation that extract the information from the repository to create a simple index.html (plus a style.css) which I am using to do some tests on the layouts.

 

Let’s start.

My first BE contribution was the port of a patch Chris Ball send me when I asked for the possibility to add a command to list all the target in the repository.

After my mail to the list Chris was kind enough to send me a little patch to implement the option, but this patch was never merged in the repository. So after some time, I ported the patch to the last revision and send it to the list.

My idea was to have a command sintax like

be target list

that show all the target present in the repository, with or without associated bug.

The patch was accepted, with one minor modification to the sintax so now the command is

be target --list

since this is now the new sintax of the be commands

© 2011 GRYS Software Suffusion theme by Sayontan Sinha