On Saturday 12 January 2002 02:54, you wrote: > On Sat, 12 Jan 2002, Matt Sergeant wrote: > > (Forwarding to the list) > > > > ---------- Forwarded message ---------- > > Date: Fri, 11 Jan 2002 17:20:05 -0800 > > From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > Subject: returning a y:tag from x: taglib > > > > Hi, > > > > I would like to write a taglib that returns tags that require > > evaluation from a different taglib. Particularly, I want > > my taglib to return PerForm tags. How exactly would I do this ? > > For this to work you have to write your taglib as a SAX taglib, rather > than using taglibhelper. It's a little more complex, but not > showstoppingly so. > > The best thing I can do is point you to the ESQL taglib, which warp your > fragile mind at first, but eventually you'll see that it calls the Util > taglib for esql:get-xml > > :-) I would think this is the kind of application where you would want "deeper" pipelines... In other words you could have 2 levels of XSP processing, the first level can deal with taglib x, and the 2nd can deal with taglib y. In many cases you can simply use 2 namespaces and combined functionality of several taglibs, but there are cases like PerForm where that may not be a good solution, so hence deeper pipelines, maybe even something like XSP -> XSLT -> more XSP -> more XSLT...
I think ultimately this kind of approach will be the norm, allowing a number of possibilities, such as some very high level (ie very abstract) taglibs to construct sequences of output tags that operate at a lower level. This could be used for instance to construct an object-relational mapping. First level taglibs could deal entirely with objects, generating output tags that deal with the database. Given some clever caching or pre-processing and some mapping tools it could be a big win both in performance and ease of development. Naturally you can still drop down to perl at any layer, giving a great deal of flexibility. It also opens up a whole world of possibilities in terms of scalability and application distribution. Using Apache's rewriting and proxying capabilities each stage in the pipeline can be delegated to an entirely different server if desired! Thus I could do XSP at one level, ship the result back to another system which could do XSLT on the result, etc. Various performance and security issues can then be isolated at specific points (ie database access can all be performed at one level, limiting possible problems with connectivity and security to a small window). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
