You gave good info on some big-picture choices I have. But I hope I can get some more specific answers. What properties or methods should I focus on understanding and adjusting, in either the XMLListener or HTMLListener? Do I need to change the GetDefaultUserXSLTAsString method? That looks pretty intimidating, but I'll give it a shot if that's what's needed. Or should I find (or create) an appropriate object to assign to XSLTProcessorUser?

I'm sorry if I'm misinterpreting the tone of your message, but it sounds like you were partly defending what the class is doing


I'm not defending what the class is doing, but I *am* defending an approach <s>. The approach is this:

XML in unlike systems is not supposed to match. It's supposed to be appropriate to the source system and it's then translated/transformed as necessary for a target system.

If it sounds like I want you to learn this, I do <g>. And not just for Excel or FoxPro reporting!

Having said that I will answer your questions, but the point is that answering them within the context of what interface this class happens to provide if you are comfortable with what I just said. If you are not comfortable with it, then yes it does seem like a lot of work for a special purpose thing, it's unconnected to a lot of basic skills that you don't think you should have to learn.

As an analogy, suppose somebody came here (actually somebody did, very recently <g>) "I have a FoxPro 2.x application, what should I move it to?" And all the answers here said "VFP"... which is an appropriate answer.

But the person who asked isn't a database developer, let alone a Fox developer. For this person to learn what s/he would have to know to follow the advice is, indeed, incredibly complicated and way too much to have to do if s/he will never have to do it again.

By contrast, if the person had been a Fox 2.x developer, you can make a reasonable assumption that the context, how much that person would have to learn to follow the advice, plus the potential benefit to his/her future work, would be reasonable, and making the effort would be appropriate.

Now, it's true that I don't know you or your context. What I know is that the class functions in a context of what will be most useful in the long run to people sending data outward from FoxPro to other applications. The skills we're talking about, as well as what the class provides, are determined in that context.

IOW, you say this:

I don't hope to learn much more about them (for now).

And in some ways, although I can help you, and I will, I think what I tell you has to be understood in this context: you will benefit, and be able to extend what I tell you only if you are willing to invest some time in this aspect of integration.

In the specific case, here's how it lays out: you determine your appropriate target (in this case, Excel). You determine how best the target will accept data, the choices being:

1. proprietary internal format which is really hard to do unless you use COPY TO ... XLS/XL5, which doesn't meet your needs
   
2. XML in Excel's spreadsheet XML format, which might work here and might be appropriate *if* you're an expert in Excel's spreadsheet XML or have enough incentive for multiple Excel projects
   
3. XML in Excel's other XML format(s), because there are more than one. I took a quick look and reckoned that they are pretty data-oriented, which sounds great except that reports aren't raw/simple data most of the time. They're laid out in some form of presentation.
   
4. HTML, which Excel accepts in a pretty straightforward way, and which -- here's the critical thing you have to realize -- when well-formed is just an XML dialect tuned to presentation.
   

So, okay, HTML looks like the right choice to me --for reports. For raw data, I'd probably go with one of XML formats. You might disagree, but the methodology you'd follow, in any of the XML-HTML cases, would be the same, which is the whole point.

Parenthetically, when the Fox team recommends XML to Excel, remember that all HTMLListener and XMLDisplayListener (its immediate parent) do is this:

• set some properties of XMLListener they get all the formatting data they needs. XMLDisplayListener does some fancy tricks with image files and general fields. This is the bulk of the work, actually.
  
• HTMLListener turns on automatically performing a transform at the end of the run
  
• HTMLListener provides the appropriate transform . It creates a customized view of the report as a result rather than the base XML, which happens to be HTML.
  

As for which properties they turn on, you shouldn't have to ask me that <s>. You can see it by simply modifying the class and seeing what's not default <s>.

The only thing you need to do, for your purposes, is to provide an appropriate transform. Specifically:

Do I need to change the GetDefaultUserXSLTAsString method? That looks pretty intimidating, but I'll give it a shot if that's what's needed. Or should I find (or create) an appropriate object to assign to XSLTProcessorUser?


You can do it either way.

All GetDefaultUserXSLTAsString does is embed the XSLT into the class so it doesn't have to be a separate file. So, if you want to subclass, you can add the XSLT there using textmerge as shown, if you want to embed the XSLT, or you can do FILETOSTR() and put the XSLT in your app, etc.

But you don't really need to subclass; you can assign the XSLT directly to XSLTProcessorUser at any time, and no you don't have to "find or create an appropriate object". If you assign a filename or a string holding the XSLT to the XSLTProcessorUser property, the assign method will take care of this for you.

But wait, there's more <s>. You could just use XMLDisplayListener, after the report run, and run the ApplyXSLT method directly, instead of having the report run do it automatically for you. Just as with XSLTProcessorUser, you don't need to create the processor object; you can pass a string or a filename as well as a processor object that you've previously set up.

And, in all three methods of asking the class family for a transform, you can also provide a parameter collection, tuned to the needs of your transform, that allows you to specify values dynamically to the XSLT at runtime.

Now we come to: what does the XSLT that you need look like?

If you are currently doing no more than this:

COPY <reportcursor> TO ... XL5

I think it would be very simple to do. It doesn't even seem like you'd need XMLDisplayListener to do it, you could do this just fine from the XMLListener output (which of course has all the methods and XSLT facilities that we have been talking about). There are no presentation details involved, IOW. I can't tell whether you would *want* them or not, and the point is I can't make these decisions for you.

But if you did use one of these classes, HTMLListener already has everything set up for you, so the the resulting code could be as simple as this:

do (_reportoutput) with 5,"ox"
ox.xsltprocessoruser = "your.xslt"
report form ? object type 5

So, suppose you set up a quick report according to your requirements. Now YOUR.XSLT just has to do this:

• set up a table
  
• handle the page header information once, regardless of how many pages there are, if you wanted column headers. Treat each label in the page header as a th.
  
• handle each instance of a detail band similarly, treating each expressin as a td.
  

Excel will handle the result in columns, just fine.

Alternatively, you can probably see that you could create the appropriate spreadsheet XML using a simple XSLT, the tags would be different from html, td, and th, but it's the same thing. You would have to go into the Excel format and find out what the tags are, and you might lose out on eventually adding some presentation details easily, because HTML does make that easy, but it is a *very* simple thing to do in either XML dialect and the method is exactly the same.

Can it be done generically? Yes, if you make the simplifying assumptions of a simple quick-report-style layout, with column headers matching the simple detail band contents. IOW, generically enough for your project, not generically enough to support in the product!

Can you do it generically to switch between HTML style and Excel spreadsheet XML? Very possibly -- and a good use for an XSLT parameter <s>. I'd say less than 20 lines in the XSLT.

Can you add groups in? Sure. You'd have to make some more simplifying assumptions about what they would look like.

Have I just written it for you by giving you this information? Pretty much.

Do you still have to do it? Yep. (Quit whining <g>.)

>L<