On Fri, 15 Mar 2002, Fisher, James wrote:
> So am I. It seems as though we are trying to code in XML. I don't know
> about you but I don't want to write code in XML. I would much prefer to
> write perl modules along with CGI/Apache::ASP/HTML::Mason to generate the
> XML that is then passed to AxKit.
Using HTML::Mason or whatever is at least conceivable, but really when it
comes down to the difficulty of writing code in XSP my simple answer is:
Don't do that.
I look at XSP as an implementation of the high-level "business logic" or
"page flow" associated with your site. The core libraries do all the heavy
lifting and have little knowledge of XML or even Web, and the XSL files
of course have presentation and content.
Here's an example XSP file from some of my own code:
<?xml version="1.0"?>
<xsp:page
xmlns:xsp="http://www.apache.org/1999/XSP/Core";
xmlns:f="res:perl/VR/Kernel/FirstTime"
xmlns:p="res:perl/VR/Kernel/Package"
language="perl"
>
<response>
<f:bootstrap-database/>
<!--
We install the kernel's package.xml file now because it has
to run during the request's cleanup process. So we need to get
everything prepared in time for the actual parameter reading.
-->
<p:save-temp-package-from-temp-file install-from-kernel="1"/>
</response>
</xsp:page>
This file generates not one, but two databases on two different servers,
then bootstraps a few core tables into those databases, then loads up an
XML-based package description file into the database.
How does it do all this? Who cares! There could be 200 or more lines of
code hidden in those calls, with complicated logic and whatnot. This is
the beauty of XSP and taglibs: The taglibs do all the freaky complex
stuff, with no knowledge that they're in a web environment, and the XSP
files just describe what an individual page should do.
Here's a more complex example: form submission.
<?xml version="1.0"?>
<xsp:page
xmlns:xsp="http://www.apache.org/1999/XSP/Core";
xmlns:u="res:perl/VR/Kernel/Util"
xmlns:f="res:perl/VR/Kernel/FirstTime"
language="perl"
>
<response>
<u:if-form-param name="go">
<f:set-database-conf-from-form use-prefix="param_"/>
<u:redirect uri="db2.xml"/>
</u:if-form-param>
... some form-printing stuff ...
</response>
</xsp:page>
This file will skip the first section initially, because "go" isn't set.
It will then print out some data relevant to the form, and the user will
submit it. The XSL file has a form in it that looks like:
<form>
<input type="hidden" name="go" value="go"/>
<xsl:apply-templates select="params/*"/>
<br/>
<submit-button/>
<br/>
</form>
(the submit-button tag is transformed later on into a pretty orange submit
button)
When the user submits the form, it hits the *same page*, which then enters
into the top bit of the XSP logic, which in turn acts on the form input.
If everything is hunky dory, it redirects to a "thanks, buddy!" page. If
there's an error, it would obviously print out the form again, but error
messages would get sent from the xsp file to the xsl file, which will
print them out in red or whatever.
So you see, once again, the complex stuff is in a .pm file (a taglib), and
the XML file contains the form and flow information. This "XSP owns the
form" idea is more formalized in our local "VRForms" taglib, or in Matt's
PerForm taglib.
If you find your XSP files getting complex, and particularly if you find
yourself wanting to use loops or variables in your XSP file, I suggest
you're going in the wrong direction. XML in general doesn't work very well
as a procedural language, so if you're not using it in a declarative or
functional way, you're asking for trouble.
> Can't we take the utilize the advantages
> of both Modules/Frameworks?! Ok, XSP is always a valid XML file and
> abstracts calls to objects in tags. Is that a reason not to use one of the
> perl code based methods?!
It's an interesting question. Part of the problem with Embperl, Mason and
friends is that it's a slippery slope. People can easily write complex
code in their web pages, and therefore often do that. Also, if you want to
use XSLT later on, you have to ensure the output of your functions is in
well-formed XML, which obviously makes your pages even larger and more
complex. Meanwhile, if you're using TaglibHelper or something similar, the
conversion to XML happens "by magic" when using XSP.
I have found that for most uses, XSP does the job well. It's very limited,
though, particularly if you don't use loops or variables (or any other
literal Perl, really), and I'm looking at ways to improve that aspect of
it.
> > understand why you cannot nest certain tags together, and every taglib has
>
> > idiosyncracies about where and how you can use it.
I use TLH across the board, for every single taglib. I don't use any
of the taglibs on CPAN. So at lest for me, the idiosyncracies are entirely
consistent.
> I totally agree. Debugging XSP is also more difficult than the perl code
> based methods and the size of the files get large quickly. This just
> doesn't feel right?! Its almost like "counter perl" and "counter unix".
> You know "small is beautiful", etc.... There is inherently more flexibility
> in using one of the perl based methods because you don't have to "fit" into
> the XSP spec. Oh and by the way XSP is not an "official" specification.
I don't understand why debugging is difficult. If your Perl code has a bug
in it, you get a "die" or something, and a big error message on your
screen. That's no different than any other templating system.
> - Probably slower than one of the perl based methods. (More text to process
> eq slower?!)
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.
> - Not an official spec so it could change any day?!
I can't say I care about that. Standards are only useful for
interoperability, really, and your XSP doesn't have to interoperate with
anything external to your development effort.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
