Alternatives to XSP? (was: Dynamic selection list)

[Toby <to...@linux.it>]

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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org