On Fri, 15 Mar 2002, Robin Berjon wrote:
> That way XSP pages are simple drivers, all the logic is hidden. This also > throws debugging problems out of the window as you find yourself debugging > real Perl code you wrote, not what the XSP engine generates. Ooh...one important thing I forgot to point out about debugging. If your library functions are decoupled from "the web", then that means they're unit-testable! Here at Novator, we have a standard I'm very obnoxious about enforcing: everything has a unit test. New functionality is added to a system in this way: a) write a UT in the module, to exercise the new functionality b) run eval-ut, note the test is broken of course c) change the module and run eval-ut on the command line constantly until your tests are working d) implement the xsp page, maybe make adjustments to UTs and functions to support some calling semantics adjustments e) throw together a basic xsl Note the testing happens *before* you even get to XSP in (d). Heck, you don't even need to use a browser to write most of your "web application"! With some newer code I'm just polishing up, we can actually start to unit-test web pages on the command line (including cookies, redirects, etc.). It was a bit difficult, but it's very much worth it. > > Actually, it's probably faster. XSP-based systems create a DOM tree > > directly, which the LibXSLT transforms directly. If you had Embperl (for > > example) generating XML, that XML would have to be parsed before it could > > be transformed. > > Yes, LibXML XSP (ie starting with AxKit 1.5) is going to be a lot faster than > using Provider::Filter to bridge to another templating system. At least, it > really should be. Sometime soon I hope to benchmark it, to verify this. Maybe in another month. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
