Some food for thought..
I have always thought of XSP as an opportunity to create dynamic xml, not as a logic layer. I run my own perl handler before AxKit that builds up an XSP page out of various xml components that represent the different parts of the page. These are inserted into a master document and this final xml page is then cached and then passed to Axkit for XSP execution. The master document includes xsp:logic at the top that initialises a object that connects to a dedicated application server I wrote. Through the connector object I can remotely create , remove and invocate methods upon objects on the app server. This allows me to keep all "business logic" away from the web server and out of the XSP. The purpose of the XSP layer in my pipeline is to help organise the data. so the construction of the xml will be defined by the data returned by the app server and the nature of the page request. The only perl code that exists in the XSPs is either XML formatting code or object method invocation code. ie, nothing sensitive. Partly why I do this is becuase our backend data sournces are LDAP and SAP and the application server acts as a multiplexor. Putting reams of code in XSP for connecting to SAP never seemed like a good option :) The xml that is finally generated by the xsp layer is then passed to XPathScript for rendering. I use XPathSciprt becuase Ive hacked it to allow me to apply nested stylesheets. This way, each xml component that was inserted into the master document may have its own stylesheet to override particluar transformations of the main stylesheet. This lets me drive the contents of the page from the XML, but the look and feel with the XPathScript. ie, I dont have decision making logic about which components are included residing in the Stylesheets. The above is an example of how I do things, it is certainly not my opinion on how it "should" be done. If this is of interest to any of you and you want more details, do ask. I was intending to contribute some optional patches/modules to AxKit to do the above but I havent had time yet and have been waiting for the rewrite of XPathScript. Tom On Fri, 15 Mar 2002, Tod Harter wrote: > On Friday 15 March 2002 12:29, Fisher, James wrote: > > > 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. > > Yeah, XSP seemed slick enough when I made a very small page or 2. But as soon > as I got to where things were at all complex I just found it was hard to > modularize. I THINK XSLT could be used to modularize XSP, which seems a > decent idea, but what I'm thinking now is that it makes more sense to just > build a small library to generate each type of tag syntax you want in perl, > much like CGI.pm's HTML generating functions. Then you can simply compose the > XML you want and ship it off to XSLT. If you want to use XSP or some other > templating mechanism, you can do that as well, and still embed the library > functions wherever appropriate. Thus I can make things like a "form lib" and > then higher level libs that do things like stick a login form into a page, or > whatever, and each one can be styled via XSLT to HTML, XHTML, WML, or > whatever you need, just like XSP could. > > > Ditto.... I went over the docs on the cocoon site again. It seems that a > > couple of their goals were the following. > > - Separate content, logic, and presentation. XSP and logicsheets were the > > first two. > > - Have a "portable" server page spec. Since its XML after all ;-) > > However, we know in the real world if you wrote a site in XSP and went from > > cocoon to AxKit you would have some things to work out. > > Well, I think that the reason XSP was invented was really because as an XML > valid syntax you can in theory build XML systems that generate XSP. That > seems to be the point with SILLY is that since a Cocoon pipeline is XML from > end-to-end that you can generate the components of the pipeline itself using > XSLT (which is what SILLY is, a very fancy stylesheet). Ultimately this may > prove out as a decent method, but I have a feeling its not the best way to do > heavy-duty logic. > > > > With respect to goal #1 AxKit solves that problem for us. We can separate > > content and logic with any of the perl code based methods. > > > > With respect to goal #2 ... Hmmm. Would a business really use this. Lets > > see if I can come up with an example. I am a business who sells some type > > of app server that will live on your servers. I decide to use XSP so (at > > least today) I can port it to and from AxKit and Cocoon. So I can tell my > > clients they can house my app server on a java app server or apache > > mod/perl. Is this realistic?! We could still port our app regardless. > > Granted, the XSP would save some work. But, does that advantage outweigh > > the disadvantages.... > > Well, I think it would NOT save work for me in the long run. I think the last > big app I wrote has about 100k lines of perl in it. Lets say 50k lines of > that does things that XSLT can do better, so if I'd written it in AxKit, it > would have been 50k lines of perl/XSP. I venture to say that even if the XSP > was 30k lines of that, thats a LOT of porting work to get it to work in > Cocoon. Given the shortcomings of XSP I would have to say its probably easier > to port my existing codebase to Java Servlets directly. Its already very > modularized, OO, and uses templates for most bulk output stuff. > > If I had it to write over, I'd use AxKit for sure, but probably not a lot of > XSP. > > > > - More typing > > - Harder to debug > > - Semi-dynamic pipeline. With one of the perl based method I can write out > > at the top of the file whatever pipeline I want. > > Yeah, that is one thing with XSP, you can't designate the XSLT styling with > logic, its kind of either stuck at the top of your XSP, or else you have to > use seperate stylechooser modules or similar (which amazingly is just plain > perl when you get right down to it). hehe. > > > - Probably slower than one of the perl based methods. (More text to > > process eq slower?!) > > - Not an official spec so it could change any day?! > > > > That's all I can think of right now. I am also interested in other > > opinions. > > > > Note: I like everything about AxKit except XSP > > I won't go so far even as to say that I DISLIKE XSP. Its a clever thing, and > I can't help feeling it has utility, but I just can't see it as a good > implementation technique for logic intensive webapps. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
