I am guessing that the "headless" version is what I do this when I am
doing a shockwave piece which calls cgi scripts. I create an html
version which provides a browser interface, albeit more boring, to
the same basic code so that I can more easily test the cgi side.
My strategy is to create two different versions of an "outputer"
class, and within the code always call it to do the printing. For
example $outputer->printResults( $x, $y); Then I create one outputer
class which outputs proper html and one which outputs what the
shockwave piece needs (much smaller). Then depending on parameters
in the cgi calls or in the database, I instantiate the proper
outputter to handle the call.
Tim
>[EMAIL PROTECTED],
>
>for a future project I'm in the need to support two different ways how our
>web based service can be accessed:
>1.) The traditional way: Handling user requests through a browser
>2.) The "headless" way: Handling under-the-hood requests which basically
>perform the same service as in 1, but without ever generating valid HTML.
>
>Of course I want to write application logic only once and reuse it for both
>scenarios above.
>
>I looked at the various template/component systems (HTML::Mason, Embperl,
>HTML::Template) and get the impression that all of them are very much fall
>into category one, where they in some way or another expect to be driven
>from a browser.
>I checked into xmlrpc (http://www.xmlrpc.com) as a way to perform the
>under-the-hood operation, but it seems to become aweful when trying to
>integrate it with a mod_perl driven site using one of the
>template/component systems.
>
>What I'm basically planning to create is an application framework which
>does not tie into the HTML generation process, but is invoked from a driver
>that sends either browser-input or headless input to the application logic
>and then filters the output to generate either headless responses (XML
>probably) or HTML output.
>
>Has anybody done somthing like this before? Are there any pointers you
>mod_perl'ers want to share with me?
>
>Thanks in advance
> Tobias Hoellrich, Adobe Systems