.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body

   1 > On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote:
   2 >> This sound like an interesting idea, but what i'd like to do is not,
   3 >> strictly
   4 >> speaking, a report. It is a full tree of html pages that are browseable,
   5 >> both
   6 >> on line and offline
   7 >
   8 > I'm not sure what distinction you're making about "report".  You're
   9 > just producing a static snapshot of the current database status,
  10 > right?  The number of pages and completeness of coverage are nice, but
  11 > it's still a static entity generated from a particular snapshot, which
  12 > is what I mean by "report" ;).
  13
  14 Mmm, my bad here.
  15 I normally speak about "report" as something that is not browseable, like
  16 the output of a report generator (reportlab or whatever), but I admit that
  17 basically also the html output I am working on is a report.
  18
  19
  20 > On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote:
  21 >>
  22 >> Ok, but if I want to have an html dump that is browseable, I need to
  23 >> parse the
  24 >> xml. Am I correct ?
  25 >> If yes, should not be easiear to use directly the libbe ?
  26 >
  27 > Using libbe directly is easier, but also more tightly tied to the be
  28 > internals which could weigh down future refactoring.  Partly I'm
  29 > afraid of our 2.5 different html-output mechanisms.  Either their
  30 > should be a single Right Way that tries to satisfy everyone, or a
  31 > smorgasbord of loosely coupled translators, so it's not so painful to
  32 > kill them if/when they go out of style :p.
  33
  34 I know that using libbe I am more tightly tied to the internals, but
  35 I am trying to keep the command code and the presentation code crearly
  36 separated to minimize this problem. I am not sure this is a real problem
  37 anyway.
  38
  39
  40 > On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote:
  41 >> On Saturday 04 July 2009 02:31:26 Chris Ball wrote:
  42 >> > It might be a good idea for "be html" to use the CherryPy web
  43 >> interface
  44 >> > that Steve is working on.  The command could start up the CherryPy app
  45 >> > and scrape all of the available pages to get a stand-alone dump; this
  46 >> > would avoid having to keep two (okay, more than two at this point)
  47 >> > separate sets of HTML templates in the source tree.  What do you
  48 >> think?
  49 >>
  50 >> It can be do, but this implies that CherryPy must be installed and
  51 >> configured,
  52 >> a thing that I don't want to impose. My idea is to offer a simpler way
  53 >> to have
  54 >> some html pages, where you just need to have BE installed.
  55 >
  56 > I agree that not needing CherryPy for a static html dump is good.
  57 > Also, read-only templates will look different from the CherryPy
  58 > interactive templates.  +1 for another quasi-redundant template set
  59 > ;).
  60
  61 The look is not a problem. I can always use the same html Steve is using.
  62 I am also playing with the idea to have the template themeable some time
  63 after I have a fully working version.
  64
  65 >
  66 >> >    > 2) I see that every command is implemented with a python file in
  67 >> >    > the becommand dir. For a better code, I'd like to split the
  68 >> >    > command implementation into two files: a file that contain the
  69 >> >    > actual code and a second file that have the html related part,
  70 >> >    > any problem with this ? I don't like to have the html part and
  71 >> >    > the code part in one big and unreadable file.
  72 >> >
  73 >> > I agree that becommands/*.py commands should not contain any HTML
  74 >> > layout code.  Putting it somewhere else instead sounds fine.
  75 >>
  76 >> I am in doubt with the "somewhere else", since for now I put the html
  77 >> template
  78 >> into a separate file in the same directory. Suggestion ?
  79 >
  80 > I think that only code intended only for command line use only should
  81 > go into becommands, but really, just dump it anywhere and we can shift
  82 > it around later :p.
  83
  84 Of course.
  85
  86 bye
  87 Gianluca
  88
  89
  90 _______________________________________________
  91 Be-devel mailing list
  92 Be-devel@bugseverywhere.org
  93 http://void.printf.net/cgi-bin/mailman/listinfo/be-devel