> > 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?
JX, flowscript, cforms (javaflow though not yet used)....Personally, I haven't used XSP's or sitemap actions (apart from the clear cache) for years, and try to avoid sql transformations as much as possible and use whatever jdo implementation to make data persistent. Regards Ard > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
