On Friday, April 11, 2003, at 01:42 PM, Kip Hampton wrote: <snip>
The content-length was different because the content returned was different. See below.
<snip>
Ok...
It does change it, though. Your patched version always returns a DOM instance, the current version serializes the result to a string using the XSLT processor's output_string( $result ) if the current process is $last_in_chain. The difference is that the latter *alters* the output based on options that may be set in an <xsl:output/> element in the stylesheet itself. The last stylesheet in my test suite had
<snip>
Ok....thats annoying! Can someone tell me how XSLT embeds the desired output format into the DOM, so that when XML::LibXSLT::output_string($result) is called, it knows to serialize in a specific manner?
Its not a big deal, all it takes is checking $last_in_chain and returning the result of output_string( $result ) if its defined instead of always returning the DOM.
Rather than this, it could be better to keep passing the DOM back (for consistancy) - but then at the final serialization stage (when sending to the client) we use a serialization method that respects the desired output format attached to the DOM. Not that it really matters.....
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
Ok....we'll use that way then. Makes no difference to me :-)
Well, really the only part I was worried about was shutting down direct access to sending data to the client from the Language modules, but, given that its only there in an illusory way now anyway, it really doesn't matter.
Cool.
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.
Then to create something suitable to my site, I might apply some XSLT to convert to XHTML. But if I wanted to include some dynamic stuff - eg. a 'Welcome <logged in user>' or even a form like 'Add new entry to blog', then I'd want to convert from the original RSS to an XSP page that could output XHTML containing the user details and perhaps the results of processing the parameters in the request...
I can certainly see situations where there is no initial data source and thus one is generated entirely dynamically via XSP based on the request parameters or similar - but I would've thought it more common to have some initial XML to work with.
Maybe I'm just being a content purist though ;-)
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?
I think it's do-able. Stage 3 wouldn't be done via a different Cache module though - it would have to be via some sort of option (AxIncrementalCache On/Off ?).
[ all: please change the subject to create a new thread if you want to discuss this point with me further. The initial discussion on this was on -users with the topic 'Adding XSP to an XSLT pipeline'. ]
This discussion is not appropriate for the user's list; that's why I brought it here. If you want to continue in the conversation you are certainly most welcome and what you do with the subject line in your replies is your business. :-)
I was actually referring to my comments on the pros/cons of putting XSP earlier or later in a pipeline....thats really a different discussion from whether the patches are good or not.
Regards, Chris
PGP.sig
Description: This is a digitally signed message part
