Background rendering of a web page for email

[Brian V Hughes]

--On 03/12/2002, Mike Myers wrote:
>I have reached a point where I can't see the forest through the trees. A
>little advice would be appreciated!
>
>Using: Frontier 8.05 on Windows NT.
>
>In response to a web form submission, I want to render a web page behind the
>scenes, grab the HTML, and mail it to a recipient(s) via tcp.sendMail. The
>HTML returned to the browser is not identical to what gets emailed.
>
>I *could* create the HTML for the email msg entirely from scratch in
>UserTalk, but there are obvious advantages to relying on Frontier's website
>framework to handle the rendering (templates, macros, the glossary). I'm
>trying to arrive at the most simple architecture.

Well, as long as you have a website table already defined, and the 
object that you want to render is present in that table, then you 
should make use of the Website Framework.

>Submit Form 1 --> Present Form 2
>                   (user enters email recipients, chooses formatting options)
>                   (selections from Form 1 passed through as hidden inputs)
>
>Submit Form 2 --> Render HTML based on selections captured from Forms 1 & 2.
>                   (Need to set some page table elements dynamically.)
>                   Email that HTML to specified recipient(s).
>                   Return some other HTML to browser
>                     eg. a summary, or return to page containing Form 1.

That sounds like a good architecture for handling what you are trying to do.

>I'm unsure of what approach to take in the "behind-the-scenes" rendering
>after submission of Form 2.
>
>   -- if I create a page table dynamically from scratch,
>      can I render it and capture the result string
>      (ala html.buildOnepage())? What are the minimal
>      elements required for a page table to function?

You actually don't need any elements in the page table, which you can 
most certainly create from scratch. If what you are looking to do is 
render the page object through the framework, but not publish the 
page, then you don't want to use html.buildOnePage. The 
html.buildOnePage script will actually call into the fileWriters 
sub-system to actually produce a page, just like if you picked 
"Publish Page" from the Web menu in Frontier. In fact, it's the 
programmatic way to "publish" a page in the background.

If, instead, you want to "render" the page, and use the rendered HTML 
is some other manner, then you want to call html.buildObject. The 
cool thing about buildObject is you don't need to actually create the 
page table, as long as you have a local variable in the script whose 
address you can pass into buildObject. However, if you want to 
pre-populate some directives, then use the new () script to create 
the page table variable, and place whatever directives you want into 
it. Just make sure you choose your directive names carefully, so you 
don't accidentally override any of the standard page table elements 
that you don't want to override.

>   -- create a physical website in the odb to act as a placeholder,
>      then use tcp.httpClient() to post the collected data to this
>      web address. Email the returned HTML. Downside: I might have to
>      create several different placeholders to hold their respective
>      prefs/customizations. Any time I create a new subsite, I would
>      have to create a corresponding dummy placeholder site. Tedious.

You would only need to do this if you plan to also use the published 
page in another context. If all you want is the rendered HTML from 
the build process, then use html.buildObject (which is what 
mainResponder.respond uses, btw), and do whatever you want with the 
returned text.

-Brian