#3 Modify the export to SQL

[michek]

Now the export scheme is hard coded! This leads to
little flexibility. It should be one of our first
updates to make this more modular, either by showing a
dialog querying all the column names (which is lits of
work everytime s.o. wants to export something) or
better to export it to XML and transform it via XSLT
which has to be provided by the user.
Tasks:
> Are there more options?
> Can the transformation be performed from the GUI?
> Implement a feasible solution!

[michek]

Logged In: YES
user_id=1340870

I will have a look into this by mid of next week. If anyone
else should feel like starting this on this problem, nm,
just give me a notice. Also you can tell me other possible
solutions than the ones stated above!
mk

[Sven]

Logged In: YES
user_id=1352033

We do already have XML export functionality so that XSL
transformation my already be used to translate it into
whatever format one desires.

It might be a lot simpler, though, if the XML-export is
enhanced to include a summary of the results in a separate
element (so that one does not have to sum up via XSLT - if
that is at all possible).

We then could change the semantics of the "Web" button to
first do the export into XML and then immediately apply a
user-supplied XSLT stylesheet to the export output (maybe
only save the transformation output to disk and discard the
XML after the transformation).

Although I feel that XSLT is a bit heavy for the task at
hand, it will provide a very powerful way for exporting the
results.

[michek]

Logged In: YES
user_id=1340870

I am well aware of the existing XML-export, however I think
that meshing those two exports up is not any good. I don't
think the present form of the XML-doc is feasible for a
transformation, cause it contains information about each
game played, and there is functionality in the code to
calucate a final result. This is nothing the transformation
should be bothered with. I neither see any reason why we
should add this information into the existing file. So IMHO
a complete independent file would be best. Besides: perhaps
some users want to include this into their database without
all the overhead?

I see the point about shooting with cannons on sparrows by
using XSLT. But I don't think a proprietary format to define
the transformations would help at all.
I keep on thinking about the possibilies, since I don't
really fancy implementing XSLT...
Another possibility might be to just provide the mappings in
a file (why not XML here), before constructing the output?
Might save lots of overhead and the correctness of the
mapping can (if we really want this) be verified via a
provided schema...
mk

[Dirk]

Logged In: YES
user_id=1276430

I think the best way would be to store all the statistic
related data into a xml file. All the over applications can
than use this file to import the data and we must not care
about the fact how they do this.<br>The idea of the actual
solution was to minimize the work for Martin. The simpliest
solution for Martin was to get a SQL statement - so he had
nothing to change in his application.

[michek]

Logged In: YES
user_id=1340870

Ok convinced. It's probably best to have everything included
into one file, just an element like
<summary>
<player id="" name="">
<money>/amount/</money>
<soliWon>/number</soliWon>
<soliLost>/number/</soliLost>
</player>
... [*4]
</summary>
at the top. Then users can include their own Stylesheets to
transform things to whereever they want...
As said: from Wednesday next week on I'll work on this!
mk