Hi AxDevers... After being submerged in my new contractor's office, which was getting hacked by some annoying trojan right away and cleaning stuff up, I'll finally give my 2 cents to this issue.
On Friday, 11. April 2003 13:24, Chris Leishman wrote: > >> It is a smidge hacky I agree. I did it to be backwards compatible. > >> I guess the same could be achieved by returning a hashref with a > >> 'status' member, and then detecting whether a scalar or a hash ref > >> was returned by the processor back in AxKit. > > > > +1 Sounds reasonable. > > XSP (eXtensible Server Pages) is all about *generating* content. It is > > not a transformative processor in the way that XSLT and XPathScript > > are. There is no XSP stylesheet that gets applied to a source document > > and there's nothing in the language itself that presumes an input > > document.. Markup, inlined code, and taglibs (markup that maps to > > code) are combined in one document and the only "transformation" > > happens when the XSP processor executes the inlined or taglib-added > > code. > > > > So, unless you mean "a pipeline of styles that generates an XSP page > > that gets executed at the end to generate further content" I'm not > > sure what you mean by using XSP as "form of styling". Its not that you > > *couldn't* do things that way, but its hardly the common case. The > > XSP(to generate content)->XSLT(to style it for the given client) > > pattern is far more common. > > Well, my way of thinking about XML based content management, is that > everything should start, where possible, from a simple XML document > that contains only the data of interest. Eg, if I wanted to display a > page that has a list of blog entries, then I'd start with some XML > similar to RSS - or if I wanted an article on my site, I might start > with a document in docbook format. These documents would either come > from a file or somewhere else based on the initial Provider AxKit uses. I have been doing quite heavy XSLT->XSP->... processing. It boils down to some data document (be it from the filesystem or generated from SQL via a nice provider I did, or retrieved from XMLDB, whatever...) that is the 'object' of some processing. A user might want to edit it, because it's his own. A user might want to add a comment, because he is interested in it, whatever. So there are actually two stylesheet directives to apply one logical transformation: The XSLT which converts the input data to some XSP page usually using some taglib which was written for that very purpose, and the XSP transformation after that. The result is some internal XML which is later transformed into the correct HTML forms, links, whatever. So this is definitely useful, especially since it makes you independent of storage. I transferred the whole site from XMLDB to SQL in a matter of a few days, including writing/extending the SQL provider. Re-doing all that in ESQL would have been deadly. Yet, let me take you off topic. Matt already said it: XSP is no styling language per se. This is a problem. The split approach can get very confusing. XSLT doesn't give you enough access to foreign data, even using perl extenstion functions, or allows you to leverage perl's module library easily. XPathScript allows you to do fairly complex processing, but lacks XSP's mix-and-match taglib flexibility. People actually doing XSP-after-XSLT are a good indicator that something is indeed missing. I agree with Matt that XSP was meant to *generate* content, but the world seems to want something between XSP, XSLT and XPathScript for active transformations. At least I want ;-) XPathScript with taglibs and some selected XSLT constructs, sort of. > Maybe I'm just being a content purist though ;-) Oh, you are not alone. I am purist of everything that makes the job easier or cooler ;-) > > Here's what I suggest: > > > > 1) Accept the patches. > > 2) Re-implement the current all-or-nothing" caching behavior of the > > current Cache.pm using the new interfaces and keep this behavior as > > the default. > > 3) Ship Cache::Incremental (or whatever) as a standard alternative. > > > > Reasonable? Doable? Anyone have thoughts? +1 from me. Variations as discussed elsewhere optionally included, I have never had much insight in the caching system, so I am not much of a judge. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
