> > > > 1st of all, the entire "document" model of serving content, go ask for a > > URL, get back the result breaks down badly. Consider a form that when > > you submit it could generate either of 2 completely different results. > > Obviously you don't want to have to COMBINE the contents of those > > results into one template with a big IF statement, that defeats the > > entire purpose of the template idea, to have something that is close in > > form to static content (so that authoring tools and non-programmers can > > deal with it). Instead it would seem that a more classic programmatic > > approach is needed, accept a request, process the request, decide what > > the result is going to be, THEN go find a template if you want and use > > that to generate what the user is going to see. Now you can once again > > truely modularize. > > When I first started playing with AxKit, I used Mason to generate XML > documents (as mentioned before). One thing that I kind of liked was > that I had complete control over the document, and could generate > <?xml-stylesheet href="<% $stylesheet_name %>" type="<% > $stylesheet_type %>"?> kinds of things to help overcome the dual > template problem.
Well, I've used things like Mason as well, (built my own long before Mason existed for that matter), and it is quite as you say. I guess what I was driving at is that each ELEMENT of a system (site, whatever) really should be able to be encapsulated and composed in complex ways. Just as GUI widget sets let you build up GUI applications, web apps need the same sort of concept. I think it CAN be done with XSLT, and something like XSP perhaps. The question is how much better (if at all) XSP is than writing a script by hand that does some processing, figures out what to do next, spits out some output, and then lets AxKit style it with XSLT? I've built a good bit of some test parts of a site and I've found that using Taglibs and XSP just slowed the process down really. By the time you figure out how to build a code generator to put code in your page to eventually generate your content (the XSP taglib way of doing things) I can write 5 pages that are equally complex that are standard filters, and they are all 100% reuseable code. So the question then becomes is XSP's XML syntax REALLY worth the price of lack of real modularity and the tricky code writing process. One answer might be that applying XSLT as a way to GENERATE XSP might be the best approach. Mr Slaymaker seems to be advocating that in his article, and its one of the major themes of Cocoon (which has the entire "SILLY" language for essentially just this purpose). Its worth exploring for sure. > > In my mason projects I always start the project thinking, "Wouldn't it > be cool if I could just write some components that would have no HTML > at all (well just one or a couple of HTML elements, like <input ...>, > or <select ..><option ..></select> - mason taglibs), and just let the > HTML designer put calls to these components in their HTML...then I > would never have to deal with HTML or the HTML Designer again! Yay!". > > Somewhere around halfway through the project, I give up, and tell the > HTML designer to just give me "templates" (in a "not XSLT" sense of > the word) for me to work from. I then take their templates, split off > common pieces into components and add calls to my code. Whenever they > make a chance, I diff the files they changes and just go and make the > same changes in my mason components. Yes, this has always been one of the big flaws with templating systems. Notice that XSLT is VERY different in that you aren't embedding one syntax into another. Its all of a piece so to speak. > > This sounds ugly (and it's boring), but it works so much better than > the alternatives I had explored (like making Mason taglibs, or mason > components with methods to generate tags). When I am notified (or > notice) that the HTML person made changes, I can go through and update > a few dozen pages in about half an hour. Well, its not workeable when you have teams of 20 or 30 developers and multi-thousand page sites with complex logic and content. Which is exactly why a lot of .com's are out of business... > > I was kind of hoping that I could use XSLT and AxKit as a panacea for > this problem. I have tools the content people can use to test > stylesheets (XML Spy, and some other free tools that I found). I give > them a sample XML document, and they can transform it any way they > want. > > Of course this doesn't work. XSLT is way too complex for most of the > HTML designers I know. I think it's great, and they think I'm nuts. At least with XSLT its just a problem of tools not yet being out there. It is POSSIBLE to use it in this way, eventually. Once designers have tools that generate XML and XSLT, things will get better ;o). > > So until there are tools that help normal people write stylesheets, I > think I am going to get stuck doing it, putting me in the same boat I > was in with Mason (although I think AxKit is sexier). In that respect, > I think XSLT is great. It's very logical and makes a lot of sense to > me. If I could just get the right interface between my perl modules > and the XSL template (Mason? XSP? Text::Template? something else), I > think I would consider this a big win even if I still had to maintain > it all myself. > > > The 2nd problem is the nature and structure of XSP itself. Its just > > plain butt ugly. Its fine as I said for putting a few snippets into a > > page, but as an actual language to implement logic in, its GHASTLY. 1st > > of all the syntax rules are insane. Sure its XML, but you can spend > > hours or days trying to understand why you cannot nest certain tags > > together, and every taglib has idiosyncracies about where and how you > > can use it. Perl and XML syntaxes don't mesh at all well either. Then > > there is the problem that you can't modularize anything at all. Just > > like the original poster here was saying. What are you going to do, > > replicate your logic all over the place? Start creating an include for > > each "subroutine" that you want? Now you run into all the reasons modern > > programming languages were born. Except with XSP its worse because your > > variables are hidden away etc. Who knows what the REAL code is!!!! > > > > Honestly it seems to me that content is content and logic is logic, and > > trying to munge the two together is a big bastardized ugliness. I'd like > > to hear some alternative viewpoints though because I'd be happy to use > > XSP if someone can point out an actual concrete benefit to it in any > > non-trivial application. > > I don't know that there is much of an alternative. To write web > applications you _must_ connect logic and content. It's just a > question of how to minimize cohesion as much as possible between the > content part and the logic part. Taglibs, XSP, Mason, are all just > interfaces between the content and the logic. Right now, I am kind of > obsessed with the idea of logic generating XML for XSLT to transform > into content, and never having the content have to talk back to the > logic. This is radically different from the way I am used to doing > things, where a piece of content has special tags to call the logic > parts. I have been wanting to use XSP for this (as opposed to > something like Mason+AxKit), so everything can come in one box > (AxKit). Well, what I'm really disagreeing with is the concept that logic should EVER be mixed in with content. They should definitely remain in seperate places... XSLT definitely accomplishes this. XSP doesn't particularly. So basically I'm dissatisfied with content munged in with data, and I'm dissatisfied with the concept that the browser should be telling the app what to present next (ie, that URL X always results in Y, and if it doesn't that you need some logic in a page to choose alternatives with). Lets face it, Apache itself is the "case statement" from hell basically. Its whole job is to decide WHAT to serve. Seems to me you're better off doing your logic, THEN using the results of that to decide what to display next. > > Anyway, I really appreciate all the information and viewpoints > everyone is sharing. It is giving me lots of interesting ideas. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
