I imported a few threads from the mailing list as wishlist bugs.

12c:uw: Bug aggregation.  Multi-repo meta-BE?
529:ow: How should we version BE?
2f0:aw: Static html report generation
22b:aw: Sorting targets chronologically
d99:aw: CherryPy interface "Cherry-flavored BE"
e08:aw: Interactive email interface

1 files changed, 93 insertions, 0 deletions

diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body
new file mode 100644
index 0000000..8991cfb
--- /dev/null
+++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body
@@ -0,0 +1,93 @@
+> On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote:
+>> This sound like an interesting idea, but what i'd like to do is not,
+>> strictly
+>> speaking, a report. It is a full tree of html pages that are browseable,
+>> both
+>> on line and offline
+>
+> I'm not sure what distinction you're making about "report".  You're
+> just producing a static snapshot of the current database status,
+> right?  The number of pages and completeness of coverage are nice, but
+> it's still a static entity generated from a particular snapshot, which
+> is what I mean by "report" ;).
+
+Mmm, my bad here.
+I normally speak about "report" as something that is not browseable, like
+the output of a report generator (reportlab or whatever), but I admit that
+basically also the html output I am working on is a report.
+
+
+> On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote:
+>>
+>> Ok, but if I want to have an html dump that is browseable, I need to
+>> parse the
+>> xml. Am I correct ?
+>> If yes, should not be easiear to use directly the libbe ?
+>
+> Using libbe directly is easier, but also more tightly tied to the be
+> internals which could weigh down future refactoring.  Partly I'm
+> afraid of our 2.5 different html-output mechanisms.  Either their
+> should be a single Right Way that tries to satisfy everyone, or a
+> smorgasbord of loosely coupled translators, so it's not so painful to
+> kill them if/when they go out of style :p.
+
+I know that using libbe I am more tightly tied to the internals, but
+I am trying to keep the command code and the presentation code crearly
+separated to minimize this problem. I am not sure this is a real problem
+anyway.
+
+
+> On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote:
+>> On Saturday 04 July 2009 02:31:26 Chris Ball wrote:
+>> > It might be a good idea for "be html" to use the CherryPy web
+>> interface
+>> > that Steve is working on.  The command could start up the CherryPy app
+>> > and scrape all of the available pages to get a stand-alone dump; this
+>> > would avoid having to keep two (okay, more than two at this point)
+>> > separate sets of HTML templates in the source tree.  What do you
+>> think?
+>>
+>> It can be do, but this implies that CherryPy must be installed and
+>> configured,
+>> a thing that I don't want to impose. My idea is to offer a simpler way
+>> to have
+>> some html pages, where you just need to have BE installed.
+>
+> I agree that not needing CherryPy for a static html dump is good.
+> Also, read-only templates will look different from the CherryPy
+> interactive templates.  +1 for another quasi-redundant template set
+> ;).
+
+The look is not a problem. I can always use the same html Steve is using.
+I am also playing with the idea to have the template themeable some time
+after I have a fully working version.
+
+>
+>> >    > 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 ? I don't like to have the html part and
+>> >    > the code part in one big and unreadable file.
+>> >
+>> > I agree that becommands/*.py commands should not contain any HTML
+>> > layout code.  Putting it somewhere else instead sounds fine.
+>>
+>> I am in doubt with the "somewhere else", since for now I put the html
+>> template
+>> into a separate file in the same directory. Suggestion ?
+>
+> I think that only code intended only for command line use only should
+> go into becommands, but really, just dump it anywhere and we can shift
+> it around later :p.
+
+Of course.
+
+bye
+Gianluca
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel