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]
