At 03:52 PM 5/2/00 -0400, Tim Gardner wrote:
>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
Tim, I have done something similar about 3 years ago with Java Applet
access to CGI versus Browser access to CGI. You might find
http://www.gunther.web66.com/JavaCGIBridge/ useful.
Of course, my constraints were different than yours may be. When you write
Java applets for the web, you want them to be as tight and small as
possible so that you limit your cross browser coding issues
(http://www.gunther.web66.com/crossjava/) and you save the client from
downloading a load of extra stuff they do not have to.
Within this context, I do NOT recommend XML at all because XML parsing is a
heavy weight process for a java applet to be downloading classes for. To
give you an idea, JavaCGIBridge's parsing code is probably less than 1k
compiled where it is a convenience method to support all the communication
code that is handled.
I do not know if Shockwave has similar issues. You may consider the
short-and-sweet pipe delimited data sent to shockwave and then a quick
parsing in shockwave's language. Of course, if Shockwave has a built in XML
parser, then you are in the clear.
The most compelling reason to use XML is when you want to OPEN the API up
to clients other than the ones you control directly. Not shockwave/java
applets but rather LWP or some batch jobs or 3rd party intermediate search
agents. XML is nice because XML parsing degrades quite gracefully (or at
least with meaningful errors) when you change the XML and others do not
follow suit.
eg you can usually do something like add a <LastName> tag to an address
book, and your clients won't care because if they don't care about the tag,
they'll choose to ignore it. If you insert a field in a pipe delimited
list, then you can throw off an entire parser. This is not so much of an
issue when you control both the client and server code though.
If you are considering XMLRPC, you might also consider SOAP which has
Microsoft backing and has a lot of improvements over XMLRPC (although
arguably those improvements have complicated things). SOAP grew out of the
XMLRPC effort. However, implementing a SOAP client or server is not
necessarily the most trivial thing in the world (same with XMLRPC -- but
XMLRPC is a simpler spec).
Sometimes it's easier just to generate the XML manually from a script and
you get almost the same benefit. What you lose by not using a standardized
RPC mechanism is being able to easily document how you are translating the
parameters to and from XML-- whereas SOAP and XMLRPC are already documented
ways of doing method calls (CGI calls) over HTTP and other protocols.
Good luck,
Gunther
>>[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
>
