diff options
Diffstat (limited to '.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body')
| -rw-r--r-- | .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body | 93 |
1 files changed, 0 insertions, 93 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 deleted file mode 100644 index 8991cfb..0000000 --- a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body +++ /dev/null @@ -1,93 +0,0 @@ -> 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 |