It seems to me that building an XSP tag lib would be one approach. Then you can embed those tags in your XML to pull in whatever variables you need. It may be that you can just use existing tag libs, like the SQL taglib.
After experimenting some with site architecture approaches and some of the various tools, and studing what other people seem to be doing it seems to me like the best general approach is to put low level logic in XSP taglibs, like functions to pull specific stuff out of databases, interfaces to external systems, and that sort of stuff, maybe building your taglibs as a thin layer over an object oriented core function library which can provide things like session services, authorization and authentication, access to databases, and all that jazz. In the XSP itself you can deal with some high level logic flow (it may be somewhat a matter of taste as to how much you do in XSP and how much in the taglib itself). Then as you say, you can provide pure styling with XSLT. It seems to me that in this sort of scenario you really don't make a lot of use of Providers at all. XSP can include content from other XML files, but its the XSP itself that is driving the application. Raw XML then becomes more like just another database file format. You MIGHT have XML that gets styled by XSLT to generate XSP that in turn gets styled again to provide final output, but that seems like an inefficient filter chain to use. I'd be more tempted to just construct an XSP <INCLUDE> facility of some sort (probably already exists). We have some powerful tools here, it is going to take a while though to get a clear picture of the best way to structure things. On Wednesday 19 December 2001 13:54, you wrote: > Hi, > > We're currently evaluating AxKit for use on our company's website > and we are having good success with it, but I have one question. > > We would like to keep all the site's content in XML files, and > transform them into XHTML using XSLT. I would also like to add > extra variables before the XML is transformed into XHTML. I'm > trying to do this without using a language that embeds perl code > inside the XML or XSLT. > > I had planned on writing a Provider module that pulls information > from a database and cookies, etc, then set it up to inherit from > Apache::AxKit::Provider::File. It would modify the XML content > stream and add extra, or set existing, parameters in the XML before > being transformed. IMHO, this is not too elegant, but this is a > starting point I am fairly certain I can get to work. > > Another thing we have tried, with good success is feed the > XML output of an Apache::RegistryFilter script into AxKit, and > have it apply XSLT to produce HTML. We could use the same > approach and make a handler load the XML, add the parameters > then have it feed the completed doc to AxKit. I'm also > confident this will work, but not optimal because I'm trying > to get AxKit to do most of the work for efficiency reasons (both > programmer and in the program code) and ideally want just focus > on the logic. > > My main goal is to seperate content, presentation and logic into > XML, XSLT, and perl modules, repectively. I am sure that someone > on this list has done something similar to what we are doing. Is > there any recommended elegant/efficient way to do this from those > that have experimented with different approaches? > > Thanks, > > Dan > > --------------------------------------------------------------------- > 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]
