Derek Hohls wrote: > Are people still writing apps in XSP? I thought that usage of XSP was > deprecated and that it had long been supplanted by other, more robust, > technologies and techniques.
Such as? I have lots of SQL queries to make, all of which depend on values gathered from the previous ones and from sitemap and request parameters. Some of them are even iterative: repeat the same query over and over in a while loop, with parameters that come from the results of the previous run, until some condition is met (think of traversing an SQL version of the Composite design pattern.) Also which database connection to use is only discovered at runtime, as the main sitemap publishes a lot of different websites, to avoid code duplication, and each one has its own database, its own CMS, it own XSL styling, and so on. What I'm doing now is: 1. I gather what I can from the sitemap, through matchers. 2. I call an action that receives that data (as sitemap parameters), does some string processing that would require a custom matcher (hence it's easier to write in a XSP action) and stores it all in request attributes, to make it available throughout the rest of the page creation process, which involves several pipelines. This first action basically discovers what it can from the request object and selects the database against which the following SQL queries will be made. There are also a pair of loops there that automatically store every sitemap parameter into request attributes and the other way round. You won't believe how much this cleaned up the sitemap. 3. In most cases then I call another action that makes the first SQL queries, again storing the results in request attributes and returning a few sitemap parameters. 4. Back in the sitemap, I choose different paths depending on whether the requested page is to be protected with auth-protect, among other things. 5. When I get to the pipeline that extracts the actual data for the page, I know basic info about the page and I know what database to use, but I still need to make many queries, using results from one as parameters to the next, or for choosing different paths (and different queries) inside the XSP itself. Some of these queries are iterative. This step is huge, so I split it into a few logicsheets, as i couldn't find another way to split an XSP into several files (#include?) 6. The XML at this point contains the generic elements of the page, plus "pointers" (in the form of cincludes) to site-specific (= sub-sitemap- -specific) flows, forms and other stuff. 7. After a few application-wide transformers, the page goes through site-specific styling and is delivered to the end user. All actions and generators are written in XSP (instead of Java) to avoid having to deal with explicit compilation and boilerplate code. I guess step 5. (the huge page generation step, split into logicsheets for convenience) could be rewritten as a series of XSL and SQL transformers, but seeing as I have a long sequence of query -> selection (= an if) -> query -> selection, let alone iteration (= a query in a while loop), I don't see how this wouldn't result in a myriad of small XSLs that do an <if> at a time, intertwined with SQL transformers. Plus I don't know which database to use until step 2. at runtime. XSP with ESQL lets me do all this and more, as everything can be specified from request attributes. This setup works quite well, but I'm open to suggestions on how to make it more Cocoon-ish. Toby -- Signed/encrypted mail welcome. GPG/PGP Key-Id: 0x15C5C2EA --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]