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
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
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
|
