aboutsummaryrefslogtreecommitdiffstats
path: root/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/body
blob: dbf3b1b552aee212c3c679cfe5ac319d5eab3019 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Gianluca Montecchi <gian@grys.it> writes:

> 1) is it ok to develop this command ? I know that this is not a fully
> featured web interface, but I am sure that it can be usefull.

Yes, definitely. I can see it being a very easy way to put one's bug
database online for browsing.

> I am open to suggestion about it of course.

Instead of a separate command for each output format, could we have a
single “produce a static report of the bug database” command, and
specify output format as an option?

How about:

    be report
    be report --format ascii
    be report --format rst
    be report --format html

Where the ‘--format’ option has a default of, e.g., “ascii”.

This would mean that you are implementing the ‘html’ format of this
putative command.

> 2) I see that every command is implemented with a python file in the
> becommand dir. For a better code, I'd like to split the command
> implementation into two files: a file that contain the actual code and
> a second file that have the html related part, any problem with this ?

This sounds quite sensible to me. The existence of a command implies a
module of the same name in ‘becommand’, but there's no necessary
implication that that module can't import modules from elsewhere to do
its work.

-- 
 \           “It ain't so much the things we don't know that get us in |
  `\    trouble. It's the things we know that ain't so.” —Artemus Ward |
_o__)                                     (1834–1867), U.S. journalist |
Ben Finney


_______________________________________________
Be-devel mailing list
Be-devel@bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel