One way would be to create a provider that supplies an XSLT stylesheet which is itself dynamically generated (perhaps using XSP) from your BDB. It would make more sense though in that case to make the XSLT beforehand offline.
JW suggested using SAX. I agree. I think you could build an AxKit::Language module that would use SAX to fire off a perl script that would examine each block of text in the source file and do the sub. You could in fact build a subclass of the standard file provider that did the same thing. Whenever AxKit asks for the source file, your provider would just kick in and do the subs as it returned the file contents. A quick SAX parse shouldn't be too deadly to performance, hopefully. Honestly though, unless your content is 100% dynamic (in which case you should do all the subs with XSP or whatever you use for dynamic content generation) you would seem to me to be better off to do this sort of thing offline. Site developers should always try to remain aware of the possible advantages of preprocessing information offline. Even the best caching scheme can't beat having static content to serve! On Friday 29 March 2002 09:23, Joachim Seibert wrote: > > Better yet just build a BDB, then you can use the DB_File > > interface and have > > a nice hash thats both reasonably fast, can be HUGE and not > > devour all of > > memory, and is easy to update with external scripts/tools. > > Yeah, this sounds good. > But how can I use a Berkeley DB with AxKit? > Can it be used in combination with XSLT? > How can the replacement be done with it? > > Many, many questions to answer ... > Thanks for your help anyway! > > Yours Jo Seibert. > > > --------------------------------------------------------------------- > 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]
