On Thursday 14 March 2002 13:49, Chris Bilson wrote: > Robin Berjon writes: > > This is untested, but it's probably a pointer in the right direction, > > which is to use <xsp:attribute> (which works very much like > > <xsl:attribute>): > > > > <esql:row-results> > > <category> > > <xsp:attribute name='name'> > > <esql:get-string column='name'/> > > </xsp:attribute> > > <!-- add book elements after I get the categories worked out --> > > </category> > > </esql:row-results> > > That did the trick. Thank you very much! > > Another question: Now my XSP file is very big. My first instinct is to > put all of the boring bits (esql:driver, esql:dburl, etc.) into a > template that I can call, but XSP doesn't seem to have anything like > templates in XSLT. I would also like to change deep loops into > subroutines (err...templates) too, so it is easier to read the > structure of the document, so it is more like this: > > <template name="category"> > <category> > <xsp:attribute name="name"> > <esql:get-string column="name"> > </xsp:attribute> > <call-template name="books-in-category"> > <parameter name="name"> > <xsp:attribute name="value"> > <esql:get-int column="category_id"/> > </xsp:attribute> > </parameter> > </call-template> > </category> > </template> > > > <template name="books-in-category"> > <xsp:comment>Call the book template once for each book > element</xsl:comment> > ... > </template> > > > <template name="book"> > ... > </template> > > I have the feeling that this is the wrong approach, and would like > to heard what others think. Thanks!
Well, I would like to comment on this, because it brings up a philisophical debate I am having about XSP in general right now. I suspect XSP began its life in much the way HTML::Mason or any of the other templating systems did, as a way to embed snippets of code in a document, basically a better "server side include". The problem is, eventually you get to the point where you want to build real applications, not just stick a bit here and there in what is essentially static content. Then 2 big problems arise with all of these frameworks. 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. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
