.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body

   1 On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote:
   2 >
   3 > Hello to everyone
   4 >
   5 > As i said in a previous mail, I am working on a "html" command for be.
   6 > The goal is to be able to do something like "be html /web/page" to have in the
   7 > /web/page directory some static html pages that basically are the dump of the
   8 > be repository, much like ditz have
   9 > This will enable a simple and fast publish of the bus list and details on the
  10 > web, at least in read only mode.
  11 >
  12 > So I'd like to ask some question:
  13 > 1) is it ok to develop this command ? I know that this is not a fully featured
  14 > web interface, but I am sure that it can be usefull.
  15 >
  16 > I am open to suggestion about it of course.
  17 >
  18 > 2) I see that every command is implemented with a python file in the becommand
  19 > dir. For a better code, I'd like to split the command implementation into two
  20 > files: a file that contain the actual code and a second  file that have the html
  21 > related part, any problem with this ? I don't like to have the html part and
  22 > the code part in one big and unreadable file.
  23 >
  24 > I'd like to hear other opinion about this.
  25 >
  26 > Thanks for now
  27 > bye
  28 > Gianluca
  29 >
  30 >
  31 > _______________________________________________
  32 > Be-devel mailing list
  33 > Be-devel@bugseverywhere.org
  34 > http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
  35
  36 On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote:
  37 > This sound like an interesting idea, but what i'd like to do is not, strictly
  38 > speaking, a report. It is a full tree of html pages that are browseable, both
  39 > on line and offline
  40
  41 I'm not sure what distinction you're making about "report".  You're
  42 just producing a static snapshot of the current database status,
  43 right?  The number of pages and completeness of coverage are nice, but
  44 it's still a static entity generated from a particular snapshot, which
  45 is what I mean by "report" ;).
  46
  47 > > > 2) I see that every command is implemented with a python file in the
  48 > > > becommand dir. For a better code, I'd like to split the command
  49 > > > implementation into two files: a file that contain the actual code and
  50 > > > a second file that have the html related part, any problem with this ?
  51 > >
  52 > > This sounds quite sensible to me. The existence of a command implies a
  53 > > module of the same name in ‘becommand’, but there's no necessary
  54 > > implication that that module can't import modules from elsewhere to do
  55 > > its work.
  56 >
  57 > The "elsewhere"  for now is the same directory, just another module
  58 >
  59
  60 On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote:
  61 > > On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote:
  62 > > > The goal is to be able to do something like "be html /web/page" to have
  63 > > > in the /web/page directory some static html pages that basically are the
  64 > > > dump of the be repository, much like ditz have
  65 > >
  66 > > I think truly interactive frontends like Steve's working on need to be
  67 > > build on top of libbe directly, since they'll need to make lots of
  68 > > small changes to the database, and it's to slow to be reloading the
  69 > > database for every change.  Static dumps like my mbox or Gianluca's
  70 > > html could just parse the xml output of `be list' and other be
  71 > > commands.
  72 >
  73 > Ok, but if I want to have an html dump that is browseable, I need to parse the
  74 > xml. Am I correct ?
  75 > If yes, should not be easiear to use directly the libbe ?
  76
  77 Using libbe directly is easier, but also more tightly tied to the be
  78 internals which could weigh down future refactoring.  Partly I'm
  79 afraid of our 2.5 different html-output mechanisms.  Either their
  80 should be a single Right Way that tries to satisfy everyone, or a
  81 smorgasbord of loosely coupled translators, so it's not so painful to
  82 kill them if/when they go out of style :p.
  83
  84 On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote:
  85 > On Saturday 04 July 2009 02:31:26 Chris Ball wrote:
  86 > > It might be a good idea for "be html" to use the CherryPy web interface
  87 > > that Steve is working on.  The command could start up the CherryPy app
  88 > > and scrape all of the available pages to get a stand-alone dump; this
  89 > > would avoid having to keep two (okay, more than two at this point)
  90 > > separate sets of HTML templates in the source tree.  What do you think?
  91 >
  92 > It can be do, but this implies that CherryPy must be installed and configured,
  93 > a thing that I don't want to impose. My idea is to offer a simpler way to have
  94 > some html pages, where you just need to have BE installed.
  95
  96 I agree that not needing CherryPy for a static html dump is good.
  97 Also, read-only templates will look different from the CherryPy
  98 interactive templates.  +1 for another quasi-redundant template set
  99 ;).
 100
 101 > >    > 2) I see that every command is implemented with a python file in
 102 > >    > the becommand dir. For a better code, I'd like to split the
 103 > >    > command implementation into two files: a file that contain the
 104 > >    > actual code and a second file that have the html related part,
 105 > >    > any problem with this ? I don't like to have the html part and
 106 > >    > the code part in one big and unreadable file.
 107 > >
 108 > > I agree that becommands/*.py commands should not contain any HTML
 109 > > layout code.  Putting it somewhere else instead sounds fine.
 110 >
 111 > I am in doubt with the "somewhere else", since for now I put the html template
 112 > into a separate file in the same directory. Suggestion ?
 113
 114 I think that only code intended only for command line use only should
 115 go into becommands, but really, just dump it anywhere and we can shift
 116 it around later :p.
 117
 118 --
 119 This email may be signed or encrypted with GPG (http://www.gnupg.org).
 120 The GPG signature (if present) will be attached as 'signature.asc'.
 121 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
 122
 123 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt