I have a slightly different, but in many ways similar, approach to Arne's. I have a standard pipeline that pretty much all site content goes through. The first few stages merge in data associated with navigation, filter out stuff that might not be required for the particular view of data you need, etc. The first stage CAN be but isn't required to be XSP, it could also be static XML. Either way XInclude does a lot of the work.
The final stage is the 'interesting' one. Depending on the type of content you require (HTML, WML, PDF, media types or whatever) you get the corresponding final output stylesheet, for example html.xsl for a vanilla HTML page view. All that does is <xsl:include> the 'chrome" and a few standard XSLT libraries for doing common things like column headers for tabular data and whatnot. The chrome contains templates that define what your navigation actually looks like etc. Personally I LIKE XSP. I think you just have to use it to DO logic and PRODUCE content. I also like Taglibs (which I am assuming was mostly what you meant by XSP in your post). Yeah, OK you have to add a line to .htaccess when you make a new one, but how often really is that? I haven't touched my .htaccess for the root of my site in a good while now. There are still a few issues like the need to restart the server when XIncluded stuff changes, but none of it is TOO big a deal at this point. On Saturday 20 September 2003 06:03 pm, Arne Claassen wrote: > From: "Jonas Oberg" <[EMAIL PROTECTED]> > > > However, HTTP being the wonderful thing that it is, things tend to go > > from bad to worse when it comes to actually handling form submissions > > and similar things. > > > > I guess one way of doing what I want to do is to create an XSP for > > every page that contains some kind of logic. Then have the XML contain > > a tag that calls that XSP, have the XSP do whatever magic is required, > > return some XML and then have XSL transform it. > > The my system works right now is like this: > > I have a chrome.xml and chrome.xsl file to allow me to have a common look > and feel. These two files contain the various common style elements of > pages. The idea is that my content is usually framed by the chrome. > > Then there is a default.xsl which includes chrome.xsl and loads chrome.xml > into $chrome. Default.xsl provides no fancy style except allowing me to put > content into the chrome frame with a couple of default style elements i > have. > > For any app that requires special style, i overwrite default.xsl with > filename.xsl. > > My applications subclass AxKit::Provider::Filter, so they can spit out XML > and have AxKit deal with them as XML files. I use XML::LibXML::Document to > construct and render my XML. > > Using these parts, any path can now be either a file or an app, dictated by > httpd.conf. > > This way I can change out the look and feel of any one page or even the > entire site without ever touching Code, plus I can support HTML and XML > clients easily. > > arne > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Tod Harter Giant Electronic Brain http://www.giantelectronicbrain.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
