[NSRT] Rejecting matches based on failed generations?

[Stuart Roebuck <st...@adolos.co.uk>]

<ignorance-exemption-clause>As far as I am 
aware</ignorance-exemption-clause>, once any generation, transformation 
or serialization stage is in progress, it is not possible to backtrack 
out of it and continue processing in the sitemap.

This means that, if you have a number of alternative matches which 
should apply depending upon a number of conditions, those conditions 
need to be checked using matchers, selectors or actions, prior to 
generation etc.

However, it is very common to have a generation process which involves 
database access, where the failure of the database selection is 
effectively the basis upon which to decide to choose a different match 
in the sitemap.  e.g. if there's an entry in database A for this 
request, display it, otherwise display something from database B or a 
static page.

This means, that it is necessary to produce an additional matcher, 
selector or action that will perform the required database selection and 
choose the match accordingly, prior to actually generating the content 
based upon a costly reapplication of the same or similar database access.

 >>> HOWEVER...

This will double the number of database accesses (in a non-cached 
setup), and increase them way beyond that in a setup where database 
accesses are cached using the standard pipeline caching mechanisms 
(because these mechanisms don't easily allow actions, matchers or 
selectors to benefit from the cached 'decision').

 >>> THEREFORE...

It would be really useful if there was a provision in the generator API 
contract to allow a match to be rejected based on some aspect of the 
generation response.  Given that, as soon as a generator starts issuing 
SAX events, a backtrack becomes practically impossible, such a contract 
would presumably be tied to the generator generating nothing.

What do others think about this?

Stuart.


            Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
      Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Systems Architect                             Java, XML, MacOS X, XP, 
etc.
ADOLOS                                           <http://www.adolos.com/>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org