Re: [lmi] calculation summaries

[Greg Chicares]

On 2006-9-13 14:21 UTC, Vadim Zeitlin wrote:
> 
>  I'd like to propose the revised plan of action, based on using libxslt for
> producing the HTML output from XML data using XSLT. We (well, mostly
> Eugene) spent some time on learning about the possibilities that XSLT gives
> us and, AFAICS, it allows to do everything we need and do it in a clean and
> easily customizable and extendible way while keeping the main C++ code
> simple so it does look like the best solution.

I agree.

Pushing anything we can out of C++ and into html, xml, and xslt
is a Good Thing for several reasons. It's easy to customize and
to extend, as you point out: people who don't know C++ (even
expert users) can do that work, and it's easier because nothing
needs to be recompiled. Simple and clean C++ is more likely to
be unit tested, and less costly to maintain. And politically
it's better to maximize what can be done without involving any
programmer, because that makes the system less dependent on any
"key person".

>  So now the plan:
> 
> 1. We need to merge libxmlpp_branch into the trunk: indeed, we need to use
>    libxslt and it doesn't make sense to redo the work already done for
>    libxml++ itself on that branch once again. I realise that this may create
>    some problems but it really has to be done and more we delay it, more
>    difficult it's going to become. The only alternative would be to do all
>    the work on libxmlpp_branch but I really don't think it's a good idea as
>    merging all the changes at once into the trunk later will be even more
>    problematic.

I will look into this soon.

> 2. Agree on the format of the XML data file. Currently it already has all
>    the data we need to produce the HTML from it but its format is a bit
>    too verbose and not ideal from the point of view of XSLT so, if
>    possible, we'd like to simplify it. I won't speak about this in details
>    because I'm not sure if this is acceptable at all, e.g. if there are
>    other tools which depend on the current format then it probably isn't
>    and we shouldn't even spend time on discussing it. But if it is, please
>    let me know and I'll post the proposed new format in another thread.

Please do propose a new format.

We have some '.xsl' files that depend on the current format. Some
may have proprietary content, so you won't see them all in cvs.
This is not a good time to change them, but I believe they should
eventually be rewritten.

Let's approach the present task as though those other files didn't
exist, and design the xml data file the way we'd ideally like it
to be. We can leave the old data file in place for now to support
the old stylesheets, then later rewrite those stylesheets to use
the new xml data file.

> 3. Create another XML file containing the information about the columns
>    (their names, titles) and format of the data. Currently it would have
>    to be modified manually if the required report format changes but the
>    plan is to allow customizing it from the GUI in the future (i.e. add
>    a "Report format" dialog which would generate this XML file dynamically)

I agree.

Right now, four formats are hardcoded:
  {[0 | 2] decimals, [true | false] show-as-percentage}
That's not as flexible as it should be. Any number of decimals
in [0, DECIMAL_DIG] should be permitted. We might also allow data
to be displayed as "basis points" (hundredths of a percent), at
least as a future extension.

The titles are a mess: " _____ __They __Look __Like __This"
because we couldn't figure out how to make apache FOP render them
in a set of right- and bottom-aligned set boxes. It'd be great to
find a better way. If we can't fix that, then maybe we need two
kinds of titles: one with the silly underscores, and one without;
or maybe a C++ function to insert them (that may not be possible
because C++ doesn't know the font widths); or even a C++ function
to remove them for reports that don't need them.

> 4. Write the XSLT allowing to transform the XML file from (2) using the
>    parameters from the XML file from (3) into HTML 3 document suitable for
>    display in both wxHTML and a standard browser. Eugene already has a
>    prototype of such XSLT (tested with manual invocation of xsltproc) so
>    we're pretty confident this can be done.

That's great.

Will it be possible to use a library instead of xsltproc? That's
the most important open question that I see. Right now, for
  File | Print
and
  File | Print preview
we use apache fop to create '.pdf' output, which requires spawning
an external program. (There are two reasons: first, it's java; and
second, the apache license and GPL2 aren't compatible, so we would
not be allowed to link to apache code anyway.) This is slow and
ugly. Of course, the gnome libraries don't have a license problem,
and it seems that we can link libxslt directly:
  http://xmlsoft.org/XSLT/API.html
but have you tried that yet?

> 5. Completely remove the current HTML generation code and replace it with
>    libxslt call applying the XSLT file (4).
> 
>  Please let me know what do you think about this plan and whether we can
> start working on it -- and knowing the relatively tight deadlines for this
> work I'd like to start as soon as possible.

Your plan seems perfect. My only concern is making sure we can
build the necessary libraries. According to this page:
  http://xmlsoft.org/XSLT/downloads.html
we'd need these four:
  libxml2
  libxml2-devel
  libxslt
  libxslt-devel
We've been using libxml2-2.6.19 for some time, and we know that
it builds right out of the box with MSYS. Have you tried building
the others for msw?

I see that the latest version of libxml2 is 2.6.26, and we can
upgrade to that as long as we can build it.