Re[2]: [lmi] calculation summaries

[Vadim Zeitlin]

On Fri, 08 Sep 2006 00:53:53 +0000 Greg Chicares <address@hidden> wrote:

GC> I'm puzzled. We already use libxml2, and M. Veillard offers
GC> an xslt processor:
GC>   http://xmlsoft.org/XSLT/
GC> Why is that not the ideal way to generate html that wxhtml
GC> can render?

 Sorry, I'm afraid I was a little confused and mixed the previous XSL-FO
discussion with this one. Indeed, there is no problem with using XSLT, the
problem was that we didn't find any (fast and portable) XSL-FO processor
which I thought would be better as it would allow us to use the same thing
for calculations summaries and the final illustrations generation.
 
 As for using XSLT, this is indeed possible. But unless I'm missing
something, we don't currently have XML file with the calculation summary
data, do we? If we do, or if, at least, it would make sense to have it for
other reasons, then this could indeed be a better solution.

GC> >  But, of course, there are further questions. The main one is whether we
GC> > want to continue using wxHTML or if we want to be able to use CSS in our
GC> > HTML. If this is the case, we can use wxActiveX class to embed Internet
GC> > Explorer into LMI under Windows and use wxMozilla
GC> > (http://wxmozilla.sourceforge.net/) to have equivalent functionality under
GC> > Unix. But doing this will require quite some work, notably on the build
GC> > system side (building wxMozilla is not for faint of heart),
GC> 
GC> That is a strong argument against it IMO.

 Yes, unfortunately, it is. Kevin (its author) is working on making it
easier to build it but the main complexity is not with wxMozilla but
Mozilla itself AFAIK.

GC> > BTW, Greg mentioned in the past that wxHTML and Mozilla didn't render
GC> > the tables in the same way, but we couldn't reproduce it: the current
GC> > HTML code seems to be rendered by Mozilla just fine.
GC> 
GC> I'll see whether I can create a concrete test case. Perhaps
GC> the problems we observed with wx-2.5.4 are gone with 2.7 .

 Maybe, 2.5.4 was quite some time ago.

GC> I tried the url you gave above, and it was temporarily
GC> unreachable, but that's normal for sourceforge.

 Usually retrying a couple of times works. It seems that they use a round
robin algorithm for choosing the server but don't prevent it from choosing
the servers which are down...

GC> Without having looked at it, I have to say I have an uneasy feeling
GC> about creating a new dependency on a library that doesn't seem to be in
GC> widespread use.

 I understand. OTOH it could be also argued that if nobody uses it but
implements his own version, how could it be in widespread use, so it's a
chicken and egg problem. I think it would be great if you could have a look
at TEng and make the choice about using it afterwards, it seems a little
unfair to discard it without even looking at it.

GC> Perhaps our needs are so minimal that writing a tiny engine
GC> would be best.

 We definitely can do this. But we should take into account the time we'll
need to spend not only on writing the code but also on writing tests and
documentation for this library. Also, I'm not sure how much sense does it
make to embed a template engine, whether an already existing one or a
custom one we're going to write, into LMI, so it would seem to me that even
if we do write such engine ourselves, we should still make it a separate,
standalone library, instead of integrating it directly into LMI in order to
reduce complexity of LMI code and coupling between the two components.

 Anyhow, all of the following scenarios are possible:

1. Put data into an XML file and use XSLT to produce HTML
2. Use HTML template and TEng
3. Use our own HTML template

 So which one should we choose? Would you like us to make time estimates
for the above approaches?

 Thank you,
VZ