I've trying to use .fwx scripts as page components like headers, nav bars, and footers...much like you would use server side includes in a static environment. I am using Server.Execute() to invoke those sub-scripts.
This works very well in this .fwx page:
This yields very tidy source files for our authors to work with, with very little program code for them to monkey with:
PageHead(), PageHeader(), and PageFooter() are little more than calls to Server.Execute('head.fwx'), Server.Execute('header.fwx'), and Server.Execute('footer.fwx'). header.fwx has some dynamic code in it, for example displaying the user's name and current lesson number.
These three functions do not return anything or call Response.Write() directly...Server.Execute does all that. As I said, this works perfectly from a .FWX file.
The problem arises when I try to use the same approach in my legacy FoxWeb templates, called from .PRG programs, ultimately writing to html_out.
In this case, if I have Buffer Output on, I don't get any of the output of the .FWX scripts. Server.Execute() returns .T.
If I turn Buffer Output off, I only get the output from the several .FWX scripts...the output I leave in html_out is disregarded.
It seems what I really need is for Server.Execute() to return the output of the .FWX script. Either that or maybe a property such as Server.ExecutedOutput or something that returns the output of the last Server.Execute(). Does such a thing exist? That would solve my problem 100%.
Or is there another way of accomplishing this? My main goal is that one single file is used as the header for all my pages, both new .fwx files and legacy .prg files.
I would'nt even mind writing a function named FWXHeader() to be called from .fwx scripts, and another named PRGHeader() to be called from .prg programs, where the two use different ways of getting the output back to the browser. However, it is highly desirable (almost critical, really) that the output generated by each actually originate from the same .fwx file.
ps. As a side note, I'm surprised that the behavior varies so greatly with Buffering On vs. Off...but that is not a great concern for the issue at hand.