Re: [lmi] calculation summaries

[Greg Chicares]

On 2006-9-7 23:01 UTC, Vadim Zeitlin wrote:
> 
>  I'd like to discuss the different possibilities for (re)implementing the
> calculation summaries display in LMI. First of all, after studying the
> alternatives, I think there is no good reason to switch away from using
> HTML. The other possibility we considered was implementing the reports
> by just outputting them directly into a wxDC but while this is certainly
> doable, using HTML is much more flexible and it will be easier to modify
> the reports later.

Okay, I agree.

> We also thought about using an XSLT processor for
> summaries like it's already done for the illustrations printing but there
> just doesn't seem to be any C++ library doing what we need which would work
> under both Unix and Windows (we looked at xmlroff and mdc-xsl but they're
> both Unix only). So we concluded that using HTML was the best we could do.
> Please let me know if anybody disagrees with this.

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

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

That is a strong argument against it IMO.

> so I think it
> would be better to continue using wxHTML unless we really, really need
> something which it doesn't provide.

Okay.

> BTW, Greg mentioned in the past that
> wxHTML and Mozilla didn't render the tables in the same way, but we
> couldn't reproduce it: the current HTML code seems to be rendered by
> Mozilla just fine.

I'll see whether I can create a concrete test case. Perhaps
the problems we observed with wx-2.5.4 are gone with 2.7 .

>  Independently of the choice of the HTML engine, there is also another
> choice to make: should we hard code HTML in the C++ code, as it's done now,
> or extract it in a separate template file and include a "template engine"
> in our C++ code which would inject the data into this HTML template. Using
> an external template should give us much more flexibility and I don't see
> any drawbacks in doing it, so I suppose this is what we're going to do.

Flexibility is good. We'd like to push work out of C++ and
into things like xml and html, where people who don't know
C++ can easily customize them.

The drawback seems to be this:

> Then the last question is how exactly to fill the HTML template.
> Surprisingly, there are very few C++ template engine libraries, in fact we
> could only find one: TEng (http://teng.sourceforge.net/). It seems to do
> exactly what we need and while it does have some problems (insufficient
> and not always clear documentation and rather strange and too verbose to my
> taste syntax, see http://teng.sourceforge.net/?page=example), I think we
> should still use it and avoid reinventing the same thing ourselves which,
> while more satisfying from intellectual point of view, would almost
> certainly take much more time. The main problem with TEng is that we'd need
> to include yet another dependency on LMI cvs as it's certainly not wide
> spread enough to rely on it being already installed. If (and only if)
> adding this dependency is really undesirable, then we should look at
> implementing the template engine with the functionality we need ourselves.

Dependencies can range from

  painless: libxml2
    on GNU/Linux, it's widely distributed already
    './configure && make' works fine even on msw
    again on msw, it's easy to build a dll
    the library is strong; we've never needed to update it
    it's C, so we don't run into C++ compiler limitations

to

  painful: xmlwrapp
    oddball perl build system
    not in widespread use
    you and I had different versions with different api's
    it never became as free of defects as, say, libxml2
    the developer abandoned it, and removed its cvs

I tried the url you gave above, and it was temporarily
unreachable, but that's normal for sourceforge. Without
having looked at it, I have to say I have an uneasy feeling
about creating a new dependency on a library that doesn't
seem to be in widespread use.

Perhaps our needs are so minimal that writing a tiny engine
would be best. Our users told us not to pretty it up. What
they need is control over what data is shown.