Re: headless operation
On Tue, 2 May 2000, Tobias Hoellrich wrote: [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? I don't quite understand the "headless" concept you're referring to. It's not a language use I've come across before, so maybe further explanation is required. But before you get back to me, take a look at http://xml.sergeant.org/axkit/ and see if it's in any way what you're looking for. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
headless operation
[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
Re: headless operation
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
Re: headless operation
On Tue, 2 May 2000, 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. This is exactly what AxKit is designed to achieve. It's not complete yet by any means. Join the list, start hacking and suggesting, and you'll shape where it goes from here. (with AxKit, association with different media devices from the standard W3C list is automatic, and picking a stylesheet based on alternates is just a plugin away). http://xml.sergeant.org/axkit/ -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: headless operation
On Tue, 2 May 2000, Tobias Hoellrich wrote: 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. I think that whay you want, contrary (and/or supplementary) to what some other people suggested, is to start by writing an API. This API should do everything _but_ handle the interface. This means it takes care of the database, business logic, report generation (in the form of data structures), etc. Then you write two interfaces against the API. One is an HTML based interface (which you could do with any of the wonderful perl embedding tools available. My personal preference is Mason). The other interface might be a set of command line executables (which can be run from cron) or an actually shell interface, or curses, or whatever. This is exactly the approach I've taken with my Alzabo project (a data modelling tool). I started by writing an API of objects that encapsulate all of the logic of representing the schema. Then I used Mason to develop an HTML interface which instantiates objects and shows them to you, as well as giving you forms to change them. I plan to also write a curses based interface. Eventually, if I have the tuits I'll be able to develop a slick GUI (Gtk? Tk? Qt? All of the above?) against the same API, without changing the core logic (except to add new features). -dave /*== www.urth.org We await the New Sun ==*/
Re: headless operation
On Tue, 2 May 2000, Autarch wrote: On Tue, 2 May 2000, Tobias Hoellrich wrote: 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. I think that whay you want, contrary (and/or supplementary) to what some other people suggested, is to start by writing an API. This API should do everything _but_ handle the interface. This means it takes care of the database, business logic, report generation (in the form of data structures), etc. Then you write two interfaces against the API. One is an HTML based interface (which you could do with any of the wonderful perl embedding tools available. My personal preference is Mason). The other interface might be a set of command line executables (which can be run from cron) or an actually shell interface, or curses, or whatever. Right - this is how my *mumble* commercial project works, sort of. It's the old MVC methodology, if I'm not mistaken. This is actually how the whole XML approach of Cocoon and AxKit works, if you think about it. Your DTD is your API, your XML is one "record" or instance of that data, and the stylesheet(s) are your views on the object. At this time AxKit doesn't provide the kind of flexibility required to deliver the sort of dynamic application that serves from databases or user input using this kind of MVC system. But I'm working on it. Hopefully others will soon too... http://xml.sergeant.org/axkit/ -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: headless operation
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
