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