Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of FlowIssues

[Vadim Gritsenko]

Christopher Oliver wrote:

Vadim Gritsenko wrote:

You may discourage usage of these objects for the sake of perfectness 
of the MVC in the documentation but I don't think you should insist 
on disabling access to them (like in FlowVelocityGenerator).

Fair?


I think you're right.

JSTL seems to take the approach of exposing session, request, and 
application properties as "implicit objects" in its expression language.

"The JSTL expression language defines a set of implicit objects"
<snip/>

So, do you think the same can be done with the elements of the object 
model?


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.


    * pageScope - a Map that maps page-scoped attribute names to their 
values
    * requestScope - a Map that maps request-scoped attribute names to 
their values
    * sessionScope - a Map that maps session-scoped attribute names to 
their values
    * applicationScope - a Map that maps application-scoped attribute 
names to their values


Sidenote: If you want scoped XML variables in XSP, take a look at xscript.

Vadim