Umm... XSPs should be compared to JSPs, and yes, we already have set of built-in objects (see any XSP java source file, or see XSPGenerator.java):
/* Built-in parameters available for use */ // context - org.apache.cocoon.environment.Context // request - org.apache.cocoon.environment.Request // response - org.apache.cocoon.environment.Response // parameters - parameters defined in the sitemap // objectModel- java.util.Map // resolver - org.apache.cocoon.environment.SourceResolver
The only thing which is missing is flow continuation and bean (new kids), but these are provided by jpath logicsheet. And I can't built them into core XSP because people want to separate flow into the block.
Between a hack-based flow implementation driven by the need to factor flow out and a clean flow implementation with no possibility to factor it out, I would vote for the second.
If the flow, in order to fit nicely in the cocoon picture, needs to accomodate changes in the internal architecture, it meanst that is should not be optional.
on the other hand, if we can find an elegant solution to keep them separate I'm all for it, but elegant integration is, IMO, more important than potential separation.
Stefano.
